Joanna said:
A Relational model may well represent entities, but it can only represent
their state, not their behaviour. The best a RDB can do with behaviour is to
have Stored Procedures littered all over the database, with no encapsulation
between data and behaviour.
no, behavior is applied to the data in relational model at runtime,
it's up to the developer where the behavior is placed. I don't really
see why you argue with this argument, as the people who create their
BO's from entities in the relational model also place their behavior in
these objects for the most part, which is a natural thing to do and is
exactly what you'll do.
*The* fundamental difference between a relational model and an object model
is that the object model aims to encapsulate data, related behaviour and
responsibility in the one entity instead of having to link those things in
application code.
but, data + behavior on data != application.
The silly thing is, if you start with the domain model and generate a
database from it, or when you start from the relational model and
generate classes from it, teh end result will often look completely the
same. So what's the big deal you're arguing about? That your classes are
formed after modelling data + behavior? But ever looked into how a
relational model is formed and how for example DFD's and DSD's are used
to construct an application?
You seem to argue that that approach is unsufficient to write good
software. No offence, but that doesn't show a lot of knowledge of what
has been used for oh, the last 20, 30 years. Please, don't make this
into a 'your way is wrong' discussion.
I would have to strongly disagree with you; an abstract relational model is
just what is says it is: an abstraction of real life bound into a model that
is more concerned with relationships (PK/FK) than it is with an accurate
representation of the real world.
It models the relations between real-world entities and what these
entities contain. It doesn't model behavior, correct. There are other
modeling mechanisms for that. After all, the classes generated from a
relational model don't have build in behavior as in business rules, as
these have to be added by the developer. That is IMHO the same way as
you'd do it. The only thing is: the way the project is set up before
people even start to think about a 'class' is different, and uses
different constructs.
Furthermore, there will be behavior outside entities in stateless
classes, which are applied to entities, probably graphs, and which
represent business processes. The great thing of these is that you can
model them after the real processes they have to automate. This greatly
enhances the maintainability of your software as you have a theoretic
description of your process and you have a 1:1 projection of that in
executable form. Wasn't it Evans who argued for a language to reach that
same level in DDD, to overcome the burden DDD has where translations
have to be made from real world processes to executable code?
There is certainly an abstract model that reflects the real world that is
neither relational no object and it is possible to derive both relational an
object models from it. But you will find that the object model requires less
'massaging' to get it to work almost exactly as the real world.
I don't find that true, as I look very differently at how software
should be written. I admit, I'm schooled with old-skool material, before
OO was mainstream at universities, so seeing the world and seeing the
business processes as OO processes, is IMHO a bit weird. However I can
understand that if you didn't have to learn everything Yourdon cs.
wrote, but instead learned what Evans and Fowler decided was the way to
do it, the world might look a bit differently, as in: how you look at
things and thus how for example business processes should be modeled.
The funny thing is about these type of discussions is that there are
apparently 2 distinct types of creating these business layers, but at
the same time, both forget that either of them can lead to a perfect
software product, however from the other's POV it looks awful.
That's the problem; I don't like the theory behind the relational model. It
forces the model away from reality in order to comply with the rules of a
storage mechanism.
Then you didn't understand the relational theory IMHO
.
I very much doubt that, which takes longer: inserting a Sales Order record
followed by a number of Order Lines within one transaction, or inserting a
Sales Order followed by a number of Order Lines within one transaction ??
No, inserting a set of orderlines in 1 transaction or inserting an
order object and a set of orderlines in 1 transaction.
With an OPF, same SQL, same thing.
no, don't cheat
. a true O/R mapper and a true domain model work
solely with objects. This means that if I want to delete 1000 objects
directly from the db, I can't do that, I have to load them into memory
first. Otherwise you'll break the concept. You see, the real issue is
the definition where the habitat of teh entity is: the memory or the
database. DDD defines it in memory. This means that to be able to work
on an entity (delete, add, modify etc..) you only work in memory, as
entities live there.
Going below that and executing a single delete query which deletes 1000
entities from the db is not correct, because it suddenly assumes that
the real habitat of the entity is the database... erm.. that's
conflicting with the earlier definition where the entity lives.
You really haven't worked with OPFs, have you ?
)
I wrote one of the market leading O/R mappers for .NET, let's say I've
been writing O/R mapper engine code for oh, the last 3 years, full time?
A well designed OPF is a highly optimised piece of kit that only loads IDs
and enough properties (usually one) to allow users to browse lists. Thus to
load a Sales Order, your generated SQL would look something like :
SELECT ID, ORDER_REF, ORDER_DATE, CUSTOMER_ID FROM SALES_ORDER WHERE ....
Certainly an object is then created for each Sales Order but not all the
properties are loaded; the rest can either be loaded on demand or the full
object will be retrieved, based on the ID, when the object is first shown
for editing. The only time that full objects are ever loaded is when one of
them needs editing; the others in the list remain as partially loaded
objects.
That's one way to do it. You can opt for full lazy loading, partial
lazy loading or load the objects in graphs at once, one query per graph
node (prefetch paths, so fetching 10 customers, all their orders and all
their order lines results in 3 queries).
Your approach as a bit of a problem with compound PK's (it forces a
single PK for entities, which can be a problem with objectified
relations) and you need more roundtrips to the db.
What I meant was that if I want to show a list of data, say 4 columns
from a set of orders and the company name, in a flat list, I just need 1
select statement and a container for that list. It's way too inefficient
to make objects first, then create a property in the order object to
reflect the customer name and make that work in databinding scenario's:
just pull the list and show it.
It was perhaps a bit of a mean example from me, I admit. The one area
where pure O/R mappers (i.e.: just objects, no other things, so no
self-constructed lists from attributes of related entities) fail is in
reporting and other list-oriented software. I mean: creating an
aggregated list of grouped data which contains data from 3 entities, is
a bit of a pain in a pure O/R mapper as it doesn't know the concept of a
field, it knows the concept of an entity.
Object properties (like Customer) contain a Customer object that only has
the ID and Name properties loaded.
I have been working with OR mapping for many years now and certainly started
with the view that classes could be derived from tables, but my years of
experience have matured my views to realise that there is a very real
impedance mismatch between relational and object models. See my example of
the Sales Order; a relational model will treat an Order Line as a separate
entity from the Sales Order that it is a part of; the object model enforces
the composite nature of the relationship by ensuring that the only way you
can add a new Line to an Order is by asking the Order to do it for you.
Since when did you ever see a real world Order Line that wasn't contained
*within* a real world Sales Order ?
If I read a single order line, it's not contained in an order object
per se. The fun thing is: it IS contained in an order entity, but that
order entity isn't loaded into memory. Now, that last sentence is very
important: it really depends on where you define the habitat of your
entities. I define that in the database, and then the relational model
is a cornerstone of my solution space: the entities live there, inside
the structures defined by the relational model. The relational model
provides the context in which the entity data is given meaning.
This clashes with your POV, in which an entity lives inside the memory
space as an object. I can perfectly understand that. However it's a
thing of different perspective on how data should be treated. You use a
totally diffent theory than I do. For me that's perfectly fine, as long
as I'm not told that I'm doing things wrong if I'm just using 30 years
old proven technology.
The object model also allows concepts foreign to relational modelling like
inheritance, aggregation and composition. Concepts that are very much a part
of the real world but that take a lot of effort to match in the relational
model; I should know, I have to write the OPFs that cross the mismatch
You make 1 mistake: the way inheritance works in classes is not the way
inheritance works with data. The problem is that with data, I can 'cast'
data from one type to the other in a database with 1 DML statement. With
classes I can't: I have to migrate the container (object) the data is in
to another type of container. For example in the situation in which I
have a manager entity object and I want to promote that manager to an
executive entity. An executive entity definition inherits from the
manager entity definition and has an extra relation: to companycar.
Now, in your world, load a manager entity into memory and promote it.
That's pretty problematic, you can't cast the manager entity to an
executive entity of course, you have to create a new executive entity,
copy over teh data and save it.
the problem is: you've modeled it as Manager table and Executive table,
and Executive table has just the Manager PK as an FK to Manager and an
FK to companyCar. Saving teh Executive again, creates a dupe in Manager.
All of a sudden the relational model is there, something you wanted to
avoid in DDD.
FB
--
