How to structure your entities
-
Currently I have something like this. Each table in the database has a class, a select and update (includes insert) procedure and usually a bunch of GetFor##### procs (CustomerGetForRegion, CustomerGetForBranch etc). Many table also have a view (vwCustomer) that gets all the related labels, where the customer table stores the CustomerTypeID the view gets both the CustomerTypeID and the CustomerType. So typically a view has 2-6 joins. The GetFor#### use the view. My dilema comes when creating the classes in C#. I natirally have a Customer class with all the ID fields and possibly a couple of list<> of child objects (Addresses, Contacts etc) but what about the labels CustomerType etc. My customer class has 2 methods, GetRecord and GetObject, fairly obvious that one gets the table and the other gets the view. Both then populate the Customer class (it has properties for the view columns that are not in the table). I experimented with inheriting the ICustomerType but that got very ugly very quickly as all my classes have the data fields and the methods for CRUD and query in them. This left me with multiple methods and properties hiding each other. I am now looking to split my classes into Customer and CustomerDB. One hold the data and services properties and List<> requirements and the other gets does all the DB IO. The floor is now open for discussion, criticism and ideas.
-
Currently I have something like this. Each table in the database has a class, a select and update (includes insert) procedure and usually a bunch of GetFor##### procs (CustomerGetForRegion, CustomerGetForBranch etc). Many table also have a view (vwCustomer) that gets all the related labels, where the customer table stores the CustomerTypeID the view gets both the CustomerTypeID and the CustomerType. So typically a view has 2-6 joins. The GetFor#### use the view. My dilema comes when creating the classes in C#. I natirally have a Customer class with all the ID fields and possibly a couple of list<> of child objects (Addresses, Contacts etc) but what about the labels CustomerType etc. My customer class has 2 methods, GetRecord and GetObject, fairly obvious that one gets the table and the other gets the view. Both then populate the Customer class (it has properties for the view columns that are not in the table). I experimented with inheriting the ICustomerType but that got very ugly very quickly as all my classes have the data fields and the methods for CRUD and query in them. This left me with multiple methods and properties hiding each other. I am now looking to split my classes into Customer and CustomerDB. One hold the data and services properties and List<> requirements and the other gets does all the DB IO. The floor is now open for discussion, criticism and ideas.
I used to take the approach that an object should know how to persist itself, but now I always split the database access out into a separate object from the domain class as it seems to me to be a reasonable separation of concerns. One object knows about business logic, runtime behaviour, validation rules, etc. but does not know anything about persistence. Another object knows how to save and load to and from the persistence store, but does not know (or care) what the target classes are used for. I find this easier to work with, and it makes it easier to separate business logic and persistence logic for unit testing (if you are into that sort of thing). Martin Fowler covered this in his Patterns of Enterprise Architecture book, where he calls it the Table Gateway pattern. Java people call it the DAO pattern, although that term has different connotations for .NET.
-
I used to take the approach that an object should know how to persist itself, but now I always split the database access out into a separate object from the domain class as it seems to me to be a reasonable separation of concerns. One object knows about business logic, runtime behaviour, validation rules, etc. but does not know anything about persistence. Another object knows how to save and load to and from the persistence store, but does not know (or care) what the target classes are used for. I find this easier to work with, and it makes it easier to separate business logic and persistence logic for unit testing (if you are into that sort of thing). Martin Fowler covered this in his Patterns of Enterprise Architecture book, where he calls it the Table Gateway pattern. Java people call it the DAO pattern, although that term has different connotations for .NET.
I have a DAL and then a single entity object, problem seems to be that a collection of the entity objects has one hell a lot of baggage in it. I'm currently working through Josh Smith's[^] article on MVVM and wondering if the level of complexity is valid for LOB apps. I look at it from a down stream support aspect. I am slowly coming around to the opinion that WPF/Silverlight is probably going to be the future UI to work with and the MVVM pattern seems to have a vote of confidence from some well respected people.