Jeff's Blog

Roles? This is definitely one of the areas I've had the most trouble with when I try to understand my fictitious Plebian U Domain. In my original model, roles defined both a person's relationship to the University either employee (of a specific type ex, Professor, Adminstrator, GroundsKeeper etc) or student (graduate, undergrad, post-grad), and status/ fulltime and part time. On my original person object there was no concept of a Roles list (it was build on .Net 1.1, so no generics). The way I had built my layers, the BLL would call into the DAL with a specific RoleID and get back a list of all people in that role.

In this retouching of my Bag-O-Tricks I'm planning on using LINQ in the BLL to make those types of selections. This gives me 2 benefits, 1^st if a person does have multiple roles I know long will need to load the same exact person record up more than once, and second I think I'll be able to simplify the scope of the Role domain object. The big problem that I've always had with my original approach is that I felt that the Role object was really trying to encapsulate 2 distinct pieces of data. 1^st the PersonToUniversityRelationShip and 2^nd the PersonEmploymentType or PersonStudentType. Right now I'm basically looking at Role to define a person as an Employee, a Student or both.

In fact I'm not even sure that I'll have a Role object in my finalized Domain, in some ways it's a vestige of past incarnations, like the appendix, that while it might not cause any issues may not serve any real purpose. The data that I'm really going to care about is going to shift to two new domain objects tentatively called PersonEmploymentStatus and PersonEnrollmentStatus. I'm inclined at least at the Database layer so that I can use FK's to constrain the values. The status tables will let me define the attributes like type of Employee as well as more detailed information like what Colleges is the person associated with.

I'm not entirely sold on this yet, but I think that in the end I will go away from using Roles and just use LINQ to JOIN the Status objects with the Person objects to get the specific Employee and Student records. Some of that will be shaken out when I start to flesh out the Status objects and see how they relate to the EmplomentHistory and StudentHistory records that I had in my original Domain set, but I'm not in too much of a hurry to choose, the PersonRole class I have is very small, and using the Generate Unit Tests facility of VS 2008 Beta 2 makes very short work of the unit test for these objects.

Currently I have only this for my PersonRole object:

thing that has always been difficult for me when I try to extract the individual entities from the domain, is knowing just how far to break things down. Think about something like a Date, in truth a Data can be thought of as three separate objects, a Month, Day and Year. In fact it wasn't on common in the days before Ajax Calendars to create a Data as either 3 separate Text-Boxes or Drop-Down Lists. Sure on the server side these fields are usually recombined to create a full Date object, but it's not inconceivable to consider the constituents as independent objects, especially for specific validation requirements, like verifying that a Date is on a Monday or Thursday.

Now I have never seen, nor would I ever recommend splitting out the a Date into 3 separate Domain objects. However I have seen ActivityDate as a fully fledged Domain object. Every table that needed to store an Activity Data would make an entry In the FKeyed Activity table, and the ActivityDate consisted of a UserID, DataTime and ActivityID. In this case the abstraction made some sense based on the reporting requirements of the System. One report that was given a very high deliverable rating was the ability to at a glance see what employee had performed what actions for a given Date Range. Sure each table could have an ActivityDate field, and some report could do multiple selects and compile the results, but for both efficiency and ease of maintenance it made sense to create a fully fledged entity. It made even more sense to push this into the Domain, as it made it very clear to all consumers of the Domain objects that the Activity tracking was really a first class object.

For this project both the first time I looked at this, and this time the Roles area really was one of the places where I struggled the most to find a clean set of fault-lines to traverse. Sure there were other areas where I could vastly improve my design, but none where I felt quite as unsure. Hopefully as I work into the BLL of this project I will start to recognize the signs of a good clean set of domain objects.