Matt said:
Penelope,
If you really want custom objects (most flexibility, extensible,
etc.); there are costs involved. You will have to custom develop your
business domain - this is what I think you mean when you say custom
business objects. Rocky's books and framework are not the purest
implementation of a business domain.
of course you don't need to implement that by hand.
I suggest you look at Eric Evans "Domain Driven Design" and/or
Nillson's book on the same subject with C#. Using DataSets or DLINQ
with LINQ; or NHibernate, .NetTiers, etc. will only get you so far. I
have been researching this topic and implementing various application
frameworks at this level. Do not tightely couple your business domain
(custom objects) with the data layer (nor inherit from these objects
to add behavior).
Please explain why you want to do this. Just saying someone shouldn't,
sounds OK but in this case it's pretty odd.
Take for example this: do you also subclass every grid control you use
on your forms and implement an interface and place your grid using code
in that subclass and place an instance of THAT class on your form? OR
do you just place a grid on your form and add the grid using code to
the form? If the latter, you're doing exactly what you say Penelope
shouldn't do with data classes.
There IS a coupling between BO's and the datalayer, if you like it or
not: a BO represents an entity, and the entity instances are stored in
the database. Didn't you just mean to avoid a coupling between entity
class and persistence logic?
Besides that, in DDD land there's a huge dispute about targeting
repositories from entities: some say it's absolutely necessary and OK,
others say it's downright wrong to do that.
Calling repositories from entities is essentially coupling your
data-oriented code to an entity's code.
Who's right? Does it really matter? NO Of course it doesn't matter.
You see, "thou shall not do this" is stupid with regards to writing
software. People should be more pragmatic, as almost all of the people
who claim that you shouldn't do this or that have no clue whatsoever
WHY they claim that, but they read it somewhere on Fowler's site or in
some book.
Some people say that having a Save() method on an entity is BAD.
Others find it NECESSARY. Are these people stupid? No, because they
have this reasoning: the 'Save()' method is behavior, and it's behavior
affecting the data inside the class, so it should be implemented on the
class it saves. Otherwise, why have behavior B in the class but
behavior C not in the class?
Although I find persistence a service which should be applied to
entities, and therefore should be external to entity classes so the
coupling between persistence logic and the entity code itself is not
there (we support both paradigms), I can understand why some people
find it logical that persistence logic is like any other behavior and
should be in the class. Who are we to judge that they're wrong, because
on what ground do we have the authority to say they're wrong and they
shouldn't like that approach? What if they find it logical so they can
understand their own code better and work more efficient?
Using DataSets or DLINQ or anything similiar is
saying your business objects look like your database. These are (2)
entirely different structures: 1. object-oriented and the other 2.
relational.
You mix two things: table oriented data-access (datasets) and object
oriented dataaccess (linq-to-sql, o/r mappers). These two aren't the
same.
This impedence mismatch only causes some to go down (my opinion) the
wrong path with trying to map business objects to generated objects
based on the data model. This mapping creates unnessesary overhead.
1) proof where the overhead is, otherwise don't claim there is
unnecessary overhead. Dyn.proxy at runtime for example creates more
overhead than you might think.
2) they're not mapping BO's to object based on the datamodel, they
REVERSE engineer the datamodel into a relational model on the level of
NIAM/ORM, so with inheritance. At that level, you can create classes
for these entities similar to how you can create tables from an
NIAM/ORM model.
You can claim all you want but the entity model at the abstraction
level of a NIAM/ORM model is what you start with too, so the starting
point is the same.
Sure, if you just generate a class per table, it's not really going
anywhere, but for example LLBLGen Pro, of which I'm lead developer of,
reverse engineers the datamodel to the level of NIAM where it allows
you to have an entity model on the abstract level you start with when
you create the BO's by hand.
So what's the difference then? The only difference I see is that you
write all the plumbing code by hand while with a proper tool it's done
for you.
In order to add some balance to this email, I would think that using
these other techniques appropriate if the tight coupling is ok; and
the application will be committed to using this same technology for
the lifetime of the application. If it is a requirement for the data
persistence layer to be swapped out in the future - you only choice
is NOT tightly couple these data objects with the other tiers of the
application. This is why I'm such a fan of the custom business
object; but this requires much planning and structuring.
Swapping out a persistence layer is almost never done, and IF it's
done, it's as much work as swapping infragistics grids on 400 screens
for devexpress' grids. Do you take measures so that you can swap out
grids? Probably not, because why would you swap out grid X for grid Y ?
Don't get me wrong, I'm not in favor of colliding everything into one
big class and have fun, on the contrary. What I'm trying to make clear
is that if people try to abstract away something, they really need to
understand why they do that. And 'because person XYZ says so' is not a
good reason. Abstracting away something creates overhead, if not at
compile time then at least at runtime, a different application design
which requires documentation for people not familiar with the
abstraction, extra work to implement the abstraction etc.
It's the same for persistence logic. I have never seen a business case
where the persistence layer had to be swappable because it would be
essential for the application. You see, it's hard to do that, as O/R
mappers today aren't just persistence layers anymore (well, nhibernate
perhaps) but entity management systems. People take for granted that if
they do:
myOrder.Customer = myCustomer;
they get myOrder.CustomerID synced with myCustomer.CustomerID. Which
code makes that happen? Not your code, unless you write it by hand.
Which is not that easy, because:
myOrder.CustomerID = _someOtherCustomerID;
has to make myOrder.Customer become null, because otherwise your
CustomerID and Customer would be out of sync.
Silly stuff? Not at all. People who use mature o/r mapper systems know
this code can help them out throughout their OWN code.
Take the way nhibernate forces you to instantiate an entity. You
always have to use a factory, to get the dyn. proxy. All fine, but what
if you swap out nhibernate for something else and you don't need to use
the factory anymore. Doesn't that factory then look unnatural, because
you use 'new' for every other object instantiation?
The world isnt black/white. There are some good ideas floating around
and it's key to get familiar with these ideas, but it's also key to
understand where they come from and WHY A is good and B is bad in
context C, because good/bad is always context bound.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
http://www.llblgen.com
My .NET blog:
http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
