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?