business objects

[Rudderius]

Hey folks,

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...

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.

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?

[Joanna Carter [TeamB]]

"Rudderius" <dr***@bestopia .be> a écrit dans le message de news:
11************* **@seven.kulnet .kuleuven.ac.be...

| 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...

They are wrong, IMO

| 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.

You are right, also IMO.

| 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?

Separation of database code from business code is highly recommended, as is
the designing of classes before database tables if practicable.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Frans Bouma [C# MVP]]

Rudderius wrote:

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 entitycollectio n 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

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Frans Bouma [C# MVP]]

Joanna Carter [TeamB] wrote:

"Rudderius" <dr***@bestopia .be> a écrit dans le message de news:
11************* **@seven.kulnet .kuleuven.ac.be...

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...
They are wrong, IMO

I always find people who claim 'that's wrong', 'that's correct', only
believable if they state why they think it's wrong or right. For the
sake of this important discussion, could you elaborate a bit?

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.

You are right, also IMO.

So, do you also limit lazy loading in these scenario's? Because lazy
loading IS persistence logic. It's an indirect way of accessing the db
through an entity object, and if persistence logic should be outside
the entity (see my other posting why that can be a good way of doing
it, but doesn't have to, thus it depends as with everything databases
;)), lazy loading should too.

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?

Separation of database code from business code is highly recommended,
as is the designing of classes before database tables if practicable.

Yay, we didn't hear that 'DDD or the highway'-speech in a long time! ;)

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------