RE: Separation of Objects from Logic 2004-12-10 - By Terry Voss
Phil,
I use #1 because I want each class responsible for the proper things,
itself. My #1 classes have load, save, and delete and are subclasses off
another layer.
One of your negatives was that they are always there even if you don't use
them. Being subclassed they are light, and small anyway.
If Microsoft in future is going into ObjectSpaces, I think you will find
derived classes there will have save,load,delete built into them.
Designing classes is about who is responsible for what and keeping things as
simple as possible within the demands of the software environment.
HTH,
Terry Voss
http://www.computer-consulting.com
MS MVP - ASP.NET
MS MCP
-----Original Message-----
From: Phil Winstanley [mailto:phil@(protected)]
Sent: Thursday, December 09, 2004 3:56 PM
To: aspnet-architecture@(protected)
Subject: [aspnet-architecture] Separation of Objects from Logic
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
|
|
