My use case scenario has defined these objects: Employee, User, Client. My database is structured similar to inheritance where the base table is named Entity (id, displayname) with a one to one relationship to Person(entityId, firstname, lastname) with a one to one to Employee/User/Client(entityId, …) tables each containing their unique fields. An Entity can be one or all three of the use case objects.
I’ve created working business objects using code generation which creates an Entity with child property of Person with child properties for Employee, User and Client. Everything is fairly straightforward in that binding is done using dot notation like Entity.Person.Employee.HireDate. I’ve also created properties IsEmployee, IsClient, IsUser which checks for null on those properties.
In Rocky’s book he talks about responsibility driven design which seems to infer that my business objects should be redesigned like Employee(entityId, displayname, firstname, lastname, hiredate). But this would create challenges when updating the database. (I’m using ado for data access).
I haven’t run into any real problems with my current business object design, but in my desire to understand best practices I am curious if I should redo my business objects, perhaps learning and implementing EF as a my data access?
Interesting case! I'm using the exact same approach, where there is one central authority for issueing identities. I was (and still am) struggling with the design.
what rocky describes, as i believe, is more about behaviour (bdd) and use case driven modeling. This means focus is on loose coupling and little reuse when it comes to properties (data holders) however more on behaviour!
My advice: keep the entity table, a single person table containing the necesary fields and create the three classes. You will find it to be more easy to maintain i think.
please let me know what you mean with difficulties on using ado. I think ef is to blunt in general!
The design approach I advocate is that your business objects should reflect your business requirements for the user scenario, not necessarily the shape of the database.
Sometimes the shape of the business scenario is the same as the shape of the database tables - that happens a lot in simple data maintenance scenarios and simpler apps.
Most apps do have more complex scenarios where the user must interact with numerous "tables" or "entities" - usually only in bits and pieces - to accomplish their task. It is in these user scenarios that an "entity based" or data-centric object model will really cause you a lot of pain, via performance problems and radically increased complexity in the app overall (especially in the presentation layer).
CSLA is designed to support behavior or responsibility based object design. Again, in some user scenarios the object behaviors require data that is pretty directly the same as tables, so the objects look like tables. But if you use CSLA to create data-centric objects for the more complex user scenario implementations of your app you can't blame me if your performance, scalability, or maintainability are poor, because that's the fault of a flawed object design.
One way to look at this too, is that if you need to use a viewmodel to reshape your CSLA objects to match the shape of your UI requirements, then your CSLA object model is not correctly designed.
In other words, using a viewmodel to reshape a CSLA business object is a clear anti-pattern.
(this is not to say that a viewmodel isn't a good idea, especially in a XAML world - but the viewmodel should be adding _actions_ or _verbs_ for UI purposes, not reshaping the properties of the business objects)
Copyright (c) Marimer LLC