 | | | RE: Separation of Objects from Logic | RE: Separation of Objects from Logic 2004-12-10 - By Terry Voss
To me this is the key: (from last post, Julian)
encapsulate what it is to be that object - i.e. all the business logic.
Terry
-----Original Message-----
From: Julian Everett [mailto:JulianE@(protected)]
Sent: Friday, December 10, 2004 8:19 AM
To: aspnet-architecture@(protected)
Subject: [aspnet-architecture] RE: Separation of Objects from Logic
Out of interest, why do you think that the latter approach would result in a
more maintainable solution? FWIW, in my experience the former model is more
maintainable and extensible as all the state and behaviour that constitute
the entity you are modelling are defined in one place. That makes the
software easier to understand, maintain and unit test. That's not to say
those objects should contain your data loading/saving functionality (which
should probably be in a separate data access layer) or factory methods,
however I'd say they should contain _all_ the methods that encapsulate what
it is to be that object - i.e. all the business logic.
Julian
-----Original Message-----
From: Iain Smallwood [mailto:call.copse@(protected)]
Sent: 10 December 2004 13:41
To: aspnet-architecture@(protected)
Subject: [aspnet-architecture] RE: Separation of Objects from Logic
Traditionally we have used the former style here. However an analyis
of maintenance in the latter style has lead me to believe that
benefits can be gained by moving to the latter style. Especially with
regards to objects that can be switched from remoted (web services)
access to direct local access. I am intending to put my current dream
into action for my next major project...so until then I cannot really
fully commit...
cheers,
Iain
On Thu, 9 Dec 2004 23:56:05 -0000, Phil Winstanley <phil@(protected)>
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
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp
IMPORTANT NOTICE
This communication contains information, which is confidential and may also
be privileged. It is for the exclusive use of the intended recipients(s). If
you are not the intended recipient(s) please note that any form of
distribution, copying or use of this communication or the information in it
is strictly prohibited and may be unlawful. If you have recieved this
communication in error please return it to the sender. The opinions
expressed within this communication are not necessarily those expressed by
Teletext Ltd.
Teletext Ltd.
Building 10
Chiswick Park
566 Chiswick High Road
London W4 5TS
Registered in England number 2694814
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp
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
|
|
|
