RE: Separation of Objects from Logic 2004-12-10 - By Kamran
People are talking about CURD behavior for their business objects for a
long time. In Microsoft world and VB especially Rockford
Lhotka(lhotka.net) is the champion of these concepts. The advantages you
wrote are really applicable. However, I see one fundamental issue with
this approach, to make my point let assume any real world object say a
Car. Does a car know how to create itself? or does it know how to
dispose itself? Even living being cannot do that. Living being can only
reproduce or create a copy/clone of them self using external processes.
Therefore, I argue, CURD is not the natural behavior for an object.
Let's assume for a moment, CURD is fine for objects. How many different
ways an object will know to create itself? Say today you are working
with MSSQL database and write all the create methods based on it.
Tomorrow you want to move to say Oracle what you will do? re-write these
objects or override the Create method or use a Factory. The first
solution is very limited second is scalable but guess what, object
doesn't know how to save or load them self :) Having a Create method
that uses Factory to Create itself is not encapsulation.
Another argument that Smart objects (objects that encapsulate
everything) can be bindable. Well yes, any object could be. This is more
of a View stuff and nothing to do with objects itself. Suppose you have
Customer and Order object. At sometime you might want to see all the
customers and their orders and other all the orders and associated
customer. In first you want to show all the customer detail and summary
of their orders and in second you want to show full detail of order and
summary of the customer. Will you design CustomerDetail and
CustomerSummary objects with full CURD support or you will create one
object and let GUI decide what they want to show? Again, first is too
much work and second is not good OO design. CustomerDetail and
CustomerSummary is nothing but two views of same underlying object
Customer, and these objects need to be bindable not the Customer object.
Hence, implement everything on the Customer object beats the purpose
and MVC pattern comes into the picture.
The bottom line, IT DEPENDS :). I will go for smart objects when I know
I have no extendability issues and going to use these objects for
end-to-end implementation i.e. creation to view. For situation where I
know I have to design for change both in backed and views I will use
light-weight objects.
What you say?
Happy Programming !
Kamran Qamar
Phil Winstanley wrote:
>Hello,
>
>I'm having a discussion with a colleague of mine at the moment about the
>benefits of differing architectures, specifically two different
>architectures: -
>
>1. Where each object is responsible for loading and saving it's data so has
>both methods and properties. Intelligent objects one might say.
>
>I want to go in what I see as both the pros and cons for each, so here goes
>
>Advantages
>
>a) No need for a separate business logic layer.
>b) Logic for managing objects is always at hand as one of the methods of the
>object.
>c) Bindable.
>
>Disadvantages
>
>a) The methods are always there even when they're not used.
>b) ... erm ?
>
>2. Where each object is just a class with properties, light weight, but
>completely dumb. All logic is performed through a separate Business Logic
>Layer.
>
>Advantages
>
>a) No tight coupling with the business logic layer, objects can be used
>independently.
>b) Objects serialize happily as they're just made up of simple types,
>string, int & Guid generally.
>c) Light weight and can be moved between layers very easily.
>d) Bindable
>e) It's the wasy Microsoft seem to do things looking at the Provider Models.
>
>Disadvantages
>
>a) The objects have no concept of how they should behave.
>b) You need to know what in the Business Logic layer to use for
>saving/loading your objects with data.
>
>Now, I'm a fan of #2 for the reasons outlined above, but I don't know enough
>about #1 to make an informed choice so would like to hear how others
>approach this.
>
>Datasets are not out of the question though I'd prefer to stay away from
>them and their typed brethren.
>
>What do you guys use and why? What do you think of the above two?
>
>Thanks,
>
>Phil.
>
>
>
>Need SQL Advice? http://sqladvice.com
>Need RegEx Advice? http://regexadvice.com
>Need XML Advice? http://xmladvice.com
>
>
>
>
>
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|
|
