"Stefan" <we******@dotne tovation.com> a écrit dans le message de news:
uc************* @TK2MSFTNGP09.p hx.gbl...
| I was hoping my fellow coders would give me some feedback on the article
| I wrote which makes use of the System.Reflecti on namespace and
| Polymorphism to demonstrate how you can create dynamic and scalable
| business objects.
Hi Stefan, Please don't take this as outright criticism of *how* you've
written the code, but I do have concerns about this approach of including
database behaviour in business class; it simply isn't necessary.
If you really want to create dynamic and scalable business objects then you
need to design an Object Persistence Framework or Data Access Layer. This
then completely separates the business concepts from the domain of
databases. Why do developers assume that the only method of storage, even
for small numbers of instances of classes should be a database ?
In a well-designed multi-tiered framework, business classes should only ever
be concerned with business logic; how they are to be persisted should be a
non-concern, from the business logic point of view.
Certainly, you need a means of examining an object in order to persist it,
and also a means of being able to create instances and populate them from
persisted state; but this should not impose one particular way of connecting
with the persisted state, however that is achieved.
..NET reflection allows you to interrogate the state of objects without any
special interfaces or base classes. If you require special treatment of
certain fields in a class, then you can apply attributes, but you could also
have a mapping hierarchy inside the OPF or DAL which allows you to specify
which fields are or are not persistable which fields in which table that
field is to be persisted in.
Your base class includes things that are relevant to lists of objects, but
they are defined as instance methods. This implies you need an instance of a
Customer in order to access a list of Customers !!?? At the very least, any
methods that relate to lists of the given class should be static so that
they can be used without an instance.
The only special features that need adding to a base business class are: a
dirty flag to indicate whether the object has been modified, possibly a
persisted flag to indicate whether this instance was retrieved from storage,
although even this can be deduced from the other "special" feature of a base
business class, which is the ID of the instance - if the ID is null then the
instance has not been persisted, as soon as it is persistent, the ID is set
to a valid value.
I have written a series of articles that discuss OPF techniques; they are
not complete, but should give you a good idea of some of the problems and
how they can be solved.
www.carterconsulting.org.uk
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
