Joep wrote:
Thanks Otis for pointing me to the article. It really gives a good overview of the three approaches:
1) dataset approach
2) entity approach
3) business object approach
I consider 3) as the way oo-designers want their UML-design be implemented.
But what about the differences between 1) and 2)?
A row is called an object. There is a 1 to 1 mapping, no intelligence in the entities so why all the hassle?
There is intelligence in the entities. There are roughly 3 types of BL rules:
1) entity field focussed: ID > 0
2) entity focussed: Order.ShippingDate >= Order.OrderDate
3) cross entity focussed: Customer.IsGoldCustomer is true if the customer has ordered n orders in the last m months
rule 1 and 2 are often implemented in entities. 3 is often implemented outside entities, in repositories or manager classes.
Furthermore, there's a difference between an abstract entity relation model and a physical datamodel. If you check out the inheritance description in the concepts section of the LLBLGen pro manual, you'll see that you can perfectly define entities, relations etc. in a relational model, but they are defined differently in a physical datamodel in your database.
Added to that, you can have hierarchies of objects, and you can't have them with tables. 2) doesn't focus on tables, it focusses on entities. 2) doesn't focus on SQL, it focusses on entities and how to manipulate them.
So 2 and 3 are close, 1 and 2 aren't. The main difference between 2 and 3 is that 2 starts with an abstract entity relation model, which is the result of your data analysis, and 3 starts from a class model. Though that's just a choice of implementation; if you look at it closely, both (2 and 3) focuss on the entity, they just define the 'live habitat' of the entity at different places: 2 defines it in the db where an entity in memory is just a mirror and 3) defines it in memory where the entity in the db is just a copy for the case when the box goes down.
