Board index » delphi » Business Objects/OPF vs Data Aware Controls

2005-12-01 06:07:57 AM
delphi179
Folks,
I am looking at architecting what I think is a better solution using
objects (real OO programming :-) ) vs "Forms" programming. What I mean
with "Forms" programming is I drag and drop controls onto a
Form/DataModule and all logic is in the specific form/Data Module
controls or properties or events on the form/Data Module.
I see a long term value, ease of maintenance, and easy to
change/extend an application using objects. Just trying to convince
myself and others that this truly is the best way to develop an
enterprise application.
The flip side is I can quickly drop a datagrid, or component X on the
form, set properties(datasource) and bingo! I have the start of a
working application. Add a few "rules" on the events of the
controls/form, and it now does what the requirements state it should do.
I may have to use the same code on multiple forms (dependencies) but
some argue that its just as quick to find and change them on multiple
forms as it is to create the business object framework so what do you
buy developing this way?
So, not really understanding all the benefits in the Business Object
paradigm, what is the argument for building an application, specifically
an application using Business Objects/ Data Access Layer/whatever vs
just RAD development drag/drop controls and wire em up? I am really
looking for some excellent reasons to help me understand why this is a
better way.
TIA,
Bill K
 

"Bill Kirkman" <XXXX@XXXXX.COM>a écrit dans le message de news:
438e2251$XXXX@XXXXX.COM...
| I am looking at architecting what I think is a better solution using
| objects (real OO programming :-) ) vs "Forms" programming.
Yaaayyyy !!! another convert :-))
| I see a long term value, ease of maintenance, and easy to
| change/extend an application using objects. Just trying to convince
| myself and others that this truly is the best way to develop an
| enterprise application.
After you have tried to maintain enough drop/click applications, you
eventually realise that there has to be a better way.
| The flip side is I can quickly drop a datagrid, or component X on the
| form, set properties(datasource) and bingo! I have the start of a
| working application. Add a few "rules" on the events of the
| controls/form, and it now does what the requirements state it should do.
| I may have to use the same code on multiple forms (dependencies) but
| some argue that its just as quick to find and change them on multiple
| forms as it is to create the business object framework so what do you
| buy developing this way?
It is oh so easy to miss duplicated code that needs changing. Developing
business objects and frameworks allows you to define your business rules and
logic without any regard for how you want to either store or display those
objects. All the logic ends up in the place you would expect to find it;
debugging becomes a breeze because custom exceptions can be raised which are
self-describing and which tell you whether you have a problem in the data,
business or UI layer. The BO layer can be tested in isolation to prove that
there are no logic bugs before you try to integrate BOs into any other
layers.
| So, not really understanding all the benefits in the Business Object
| paradigm, what is the argument for building an application, specifically
| an application using Business Objects/ Data Access Layer/whatever vs
| just RAD development drag/drop controls and wire em up? I am really
| looking for some excellent reasons to help me understand why this is a
| better way.
BOs don't preclude the use of RAD; the problem with Delphi for Win32 is that
you would have to create all the RAD designers yourself. Now .NET,
especially 2.0 allow direct connection of data-aware controls to objects and
their properties. I am in the middle of porting all our OO frameworks to
.NET and am ditching code necessary in Win32 that just is no longer required
to create RAD applications due to the extra functionality of the .NET
framework and designers.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Bill Kirkman writes:
What I have found out is that you can not answer that question in a single
post. For me (so far) I have found that the benefit lies in trying to
get a grip on a few key technologies that are "new" (its embarrassing
to me how far behind I have gotten) and recognizing how they integrate
and what they can do to improve your products.
To me those technologies that you will have to get a grip on are:
1: Refactoring: I just got Martin Fowler's Refactoring: Improving the
Design of Existing Code. Basically, its a systematic and methodical
way of converting your old click event/top down code into true OO code.
Presuming the code already works, you make many small incremental
changes and test. Its a daunting task for those of us with huge legacy
systems.
(Yes, the forms and components you use are objects, and you have used
lists and classes where needed, but if you're like me, 80-90% of the
code written INSIDE the event handlers is top down.)
Persoanlly, I don't think I will be able to refactor my old legacy code
in exactly the manner prescribed. I say that because we are planning a
rewrite, so investing time into the old code is not worth it. HOWEVER,
as I migrate the functions and behaviors to the new system, I will
definitly be refactoring, so I guess that counts.
2. Design Patterns: Basically, there are class/object models that are
tried, tested and proven to help solve most programming problems.
Using these models will improve your architecture.
The "Bible" of Design Patterns is from Eric Gamma, et al commonly known
as the Gang of Four. GoF patterns are those described in their book.
Mine's on order, but like most "Bible's" I hear its not easily read.
Check out my other posts this week, the experts here have been kind
enough to recommend a few other pattern books. (The Delphi book on
patterns is out of print and dead at the publisher. Joanna is going to
give us all an email address so we can mail bomb him into reconsidering
:-) ).
3. Unit Testing: I was fortunate enough to attend Borland's developer
conferance and caught Charlie Calavert's talk on Unit Testing. (That
and Marco Cantu on Delphi design patterns are what got me started on
these topics! Thanks, Charlie & Marco, can not wait for the conferance
CD). Charlie's notes for both 2004 & 2005 can be found at
www.elvenware.com/charlie/conferences/2004/talks/. I highly
recommend the notes on patterns, but even more so on Unit Testing. Get
DUnit and play with it!
Basically, IF your code has been written as objects (see Refactoring
and Design Patterns) then the objects should be able to be instantiated
OUTSIDE of your application. (Yes, objects link to other objects, so
the advanced course in unit testing introduces stub & mock objects).
DUnit is a framework for writing tests that can be run against
instances of your objects outside of your program. It includes a GUI
for running the tests and reporting the results. I hear there are
other frameworks, too.
Be forewarned that you might need a primer in UML to really understand
many of the books you will encounter if you persue this. I am not an
expert in these topics by any means. Its a daunting learning curve,
but I don't see any choice. It just makes too much sense not to work
(although I am skeptical of the claim that the time spent in better
design, building thousands of tiny objects and tens of thousands of
individual tests pays off in time saved later. Better apps, yes. But
its seems to me that it is going to slow development. Admittedly,
because its so new to me that its certainly slowing me down right now.
In addition to Charlie Calavert and all the books you'l find referenced
if you scan this newsgroup, I recommend Jim Cooper's and Joanne
Carter's articles (again, just scan the newsgroup, go to their
websites) and I am sure many others. I have started reading those as
well, and while I don't understand everything yet, its exciting. I'll
build a more solid base knowledge when the books come in and tackle
these articles again.
--
 

Bill Kirkman writes:
major overhaul of an existing app, then yes, the framework probably
makes sense. But how do you build a solid framework without SOME
understanding of patterns?? Check out Jim Coopers OPF article.
Instinctively, we KNOW this will produce better results as soon as we
get some experience with it. But how to get the experience?? Real
businesses don't have time for tough learning curves - too risky.
head way this time.
First, I am learning as much as I can and trying to keep my mouth shut
until I do. (That last part isn't working so good, so I wind up
defending things I don't fully understand.) Second, I extracted the
first example from Martin Fowler's Refactoring book. In this example,
he takes a top-down sample program (the typical educational type with <
100 lines of code) and gradually changes it to an OOP consisting of
several true objects. I skipped a few steps when explaining it to my
managers/team mates because it was the comparison of old to final
result that I wanted them to focus on. Then I showed them the DUnit
test app I had written for the new OOP program. Now that the program
was written with objects, it was far easier to test this way.
Now they just have to decide if the concept is extensable to our large
systems and worth the extra cost/time of learning.
 

Bill Kirkman writes:
environment we find ourselves in.
We've been bought by a company that wants us to make major changes to
our system. They like our program, but find the interface slow and too
detailed for their needs. They want high speed, more stream-lined data
entry system. Also, they are considering a thin client/web interface
since new laws mean that the data should be securly stored at a central
location. Finally, they don't like the back end database system we are
using for the same reason.
What they really want is for us to customize our program for their
in-house needs and to also maintain it for our current distributed
client base. Yikes!
Well, if we redesign it using n-tier, it becomes a more practical
problem. We can write multiple interfaces that communicate with the
business rules via a common interface layer. And we can support
multiple database storage systems for our old client base with an OPF.
Somewhere in the middle tiers, we can worry about firewalls, etc.
So, the ideas I have been pushing (albeit with less understanding until
recently) are already starting to fall on fresh ears.
Finally, because of my inexperience in this field, they are considering
hiring an OOD-Agile consultant and attaching him to my hip for a few
monthes. Yeah!
--
 

Iman L Crawford writes:
an Agile, OO system with unit testing, etc. is NOT likely to be worth
the cost, IMO.
I was referring to building from scratch.
--
 

Thanks Steve and Joanna,
I have read Joanna's articles, Philip Brown's articles, and reading
"Beginning C# Objects by Jacquie Barker and Grant Palmer which I would like
to say is just the right book at just the right time to finally cement
some of the UML and OO theory to coding/design practices for me.
So, I believe this is the way to go, it is just there are some good
arguments that others are bringing up that I feel need to be countered.
I am in a group that has done drag/drop control and forms development
for the last 7 years in Delphi and we are now moving to ASP.NET 2.0 and
VS2005 (reasons are many and I don't want to drift off topic).
Steve, I just don't want to bite off too much at once here. Just to get
to a layered architecture is what I think is a good start. From there, I
am hoping we can move towards unit testing and refactoring, with
refactoring probably coming right on the heels of a framework. BTW, I am
learning this as I go so my inability/lack of understanding is seen as a
stumbling block to the "vets" doing drag/drop. I can understand it
though. The veterans of drag/drop say,"Why would I change from a
successful way of doing something based on "opinions" of someone who
can't counter what I consider good reasons to stay with drag/drop?"
Steve Wash writes:
are probably fresh in your mind. Did others try to counter/resist this
effort? What did you say to them? What process did you try to move to a
framework, ie. we did one small project using these techniques then
analyzed what we thought/experienced and decided this was better.
at least that or more. Yet we all felt it was Object Oriented Programming.
needed. Just too much at the moment.
applications using this process takes time and GOOD counterpoints.
That's what I am trying to assemble now.
Joanna, In your first article you had some good points about why you
were looking at an OPF vs drag/drop programming. Do you have an updated
version of points now that you are working with ASP.NET 2.0? I am
thinking Datasets may be another way to slowly move to Business
Objects/Data Access layers. What I want to be able to convey and show is
that the speed/less code gains from using drag/drop process do not go
away if you move to a framework (meaning layered architecture). Do you
have any metrics from any of your earlier work that proved to you
programming drag/drop vs framework actually saves X time/money/effort?
The current biggest concerns I am hearing are in my original post.
1)its just as quick to find and change them on
multiple forms as it is to create the business object framework so
what do you buy developing this way?
2)what is the argument for building an application,
specifically an application using Business Objects/ Data Access
Layer/whatever vs just RAD development drag/drop controls and wire em
up?
My audience are seasoned veterans that have delivered many successful
applications with drag/drop techniques in Delphi.
Thanks so much and keep the comments rolling :-).
BK
 

"Steve Wash" <XXXX@XXXXX.COM>wrote in news:438f205c$1
@newsgroups.borland.com:
worse, just different. Some things will be easy and some overly
complicated.
--
Iman
 

While I agree that asking the question of whether or not an Business
object/OPF framework might be a worthwhile endevour, I must point out a few
things:
1. Business Objects/OPF and data aware controls are not mutually exclusive.
You are talking about 2 different things. One is data persistence while the
other is data presentation. While it is true that MOST applications that
use data-aware controls do not use an OPF, this is not true of all
applications.
2. You can achieve some of the same benefits of separation of concerns and
clean, almost-zero code UIs using datamodules that connect to back-end data
sources such as DataSnap servers, webservices or the like.
3. You can derive benefit from refactoring without using an OPF.
4. You can derive benefit from Unit Testing without using an OPF.
6. You can derive benefit from Design patterns without using an OPF.
7. You can derive benefit from object modelling (UML, CRC or other) without
using an OPF.
8. You can derive benefit from using Agile development techniques without
using an OPF.
So in summary, while going the OPF route may be a good thing, just make sure
you are comparing apples with apples. You can not claim that your application
is better because you used an OPF when you also added all the other things.
It could easily be said that your application is better because you applied
any one or a number of the above features including, but not limited to the
use of an OPF.
OK. I think that is enough for now...
-Trevor
 

Steve Wash writes:
framework would follow Scott Ambler's or Joanna's overall design in
their respective articles along with what I am current studying now in
Expert C# Business Objects by Rockford Lhotka (Apress). So, it will
indeed use patterns. I just didn't think I needed to tell
management/vets about it yet since I know just enough to be dangerous on
patterns.
could learn it from those that have experience in it. But, since that's
not been the case in my career I want to take the initiative, if possible.
Too risky is definitely the initial view I am sensing from others along
with increased time to develop and will it work.
it. In my case, I have brought the idea forward, and folks are discussing
it so now it is put up or shut up time.
The thought is to use this in new application development, not refactor
a legacy app. So I do see this as a building block to start using the
techniques and get started on a framework that we will extend over time
as other new apps are brought online.
BK
 

Steve Wash writes:
that need to be updated for either zero deployment(web applications),
maybe do some web services, and maybe even WinForms apps. We control the
hardware and can dictate the software to some degree (OS and browser).
Decent performance and greater value software for our customers is the key.
I guess basically try to move from 1990's to 2005 :-).
don't see it happening anytime soon. I am looking at other avenues to go
down and get 'er done.
BK
 

Trevor de Koekkoek writes:
true OO programming, refactoring, patterns, and unit testing I believe
are are the way to move forward in application development today for
many reasons stated above and more. After drag/drop programming for 8
years there has got to be a better way!
I saw an opportunity in a new application we are about to start
developing. Thinking it would be great to get started in creating a
beginning set of business objects we could then reuse and extend as we
built other applications.
As I went down that route it was appealing to take another step and add
building an OPF to complement the business objects. This would provide
us a persistence mechanism for the BO's, and move us into true OOP,
refactoring, and get our feet wet with patterns. Maybe those of you that
have done this will say that is too much. I would also like to hear that if
it's true.
I believe Bob Dawson has a reply in this group about a scaled down
version of an OPF. Just a data access layer. I don't remember for sure,
though. Is that a better starting place since we (the developers) will
be new to this?
BK
 

Steve Wash writes:
[snip]
Please trim quoted material.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"We've all heard that a million monkeys banging on a million
typewriters will eventually reproduce the entire works of Shakespeare.
Now, thanks to the Internet, we know this is not true." - Robert
Wilensky
 

principles from now on can help a lot. You have to make a decision as to when
the risk is worth it (and there will be more risk, because you won't have a
complete suite of unit tests and so on).
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

:-) You can not always justify it from a business POV, sadly. Also, OPFs are
simple to write to do the basics (load, save, delete), but can get quite
complicated from there. OPFs that try to be general purpose get extremely
complex (eg Bold and ECO). You don't have to write your own, of course.
But I agree with Trevor. The other things are more important.
Cheers,
Jim
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________