Rudderius said:
I have a toppic I would like to discuss:
Many authors write that business objects should have the CRUD
behavior implemented (create, read, update, delete). Which means that
a class Customer has a method Load() etc...
Depends on how you look at things. In software development land, too
many things are considered 'WRONG' and 'THE ONLY RIGHT WAY'. This is of
course nonsense, as it depends on the situation and way of how you look
at things what's wrong and right.
Take your example. One can argue that an object contains data +
behavior. You can argue that having persistence logic in that object is
correct, because it's behavior too.
Others say: "no, that's not good, persistence logic should be factored
into another class". This is OK as well, if you believe the right
philosophy is to keep entity focussed behavior inside the entity object
and persistence behavior outside the entity object. It then becomes a
service, which is applied to the entity objects.
The last group cheats though. If you believe persistence logic
shouldn't be in the entity object, neither should lazy loading. After
all, it's an indirect persistence trigger.
This is particular important, because if you have set up your
application using several tiers, and you force your GUI team to use a
BL tier for all their persistence needs. So the GUI team shouldn't be
able to fetch / retrieve any data from the DB themselves, they should
only utilize the BL tier. You can only achieve that if you use
persistence as a service, and done in full, so no lazy loading as well.
In my opinion this is not the right way, because this means that you
implement the way a class is saved in the class itself. What I do is
creating DataAdapter classes for the business object. e.g.
XMLDataAdapter, SqlDataAdapter, TxtDataAdapter etc. The all implement
the same interface DataAdapter who has the CRUD behavior.
It's a way of doing it. Our o/r mapper supports both philosophies, so
you can take your pick. This is done because not everyone thinks the
same about how things should work or be designed, and as you can't
simply say 'this is right' and 'this is wrong', you can't force one way
of thinking on everyone.
If you firmly think that persistence as a service is the correct way,
for whatever reason (as the reason doesn't matter!), you should follow
that of course, and if you think persistence is behavior, you should
follow that. I can only say that if you think persistence is part of
behavior and you then use a session style / adapter style persistence
object, it's incorrect with the philosophy you've chosen. So 'not the
right way' is only relative to the context of what you think is
correct, and as I tried to explain: there's no golden rule which always
is right or wrong.
The way I do it, it is possible to save the same object as a
textfile, as an xml string or in a relational database (Sql Server
e.g.)
What do you guys think is the best way?
depends.
For a quick and dirty app, having the save logic and lazy loading
inside an entity or entitycollection is very productive. Though as I
explained earlier, it might be that in a large team, there are certain
rules which forbid parts of the team to access persistence logic and if
they still want/need to work with entity objects, it's key to have the
persistence logic outside the entities. As I said, it depends. It's not
as black and white as some people want you to believe. Heck, the
majority of software using a database is written with DTO's.
FB
--
), lazy loading should too.