Domain Objects

Domain in the Box Part 4

Jeff Mayeur — Mon, 29 Oct 2007 05:18:45 GMT

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:

public class PersonRole
{
public int? RoleID { get; set; }
public string RoleName { get; set; }
public string RoleDescription { get; set; }

public PersonRole()
{
}

public PersonRole(int? roleID, string roleName, string roleDescription)
{
this.RoleID = roleID;
this.RoleName = roleName;
this.RoleDescription = roleDescription;
}
}

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.

Domain in the Box Part 3

Jeff Mayeur — Sat, 27 Oct 2007 05:47:07 GMT

So how to handle contact info, do I make a "type level" domain object like an Emergency or Home, or do I save that sort of logical grouping for the Business layer. Truthfully I've already made up my mind. The domain layer I'm updating doesn't make any groupings, and here's why. Essentially I tried to look at the domain objects as whole entities onto themselves. An email address really has nothing to do with a mailing address, and any association like "emergency" is purely a matter of interpretation. Another way to look at it is I didn't really want my domain layer making what I thought was a business decision to allow something like an emergency email. It's the prerogative of the BLL to decide what Types of each entity the system can created. Perhaps for the grouping of emergency the BLL determines that Phone-Number is the only valid entity to create and maintain.

So if that sounds like a reasonable approach then it's not too hard to draw out where I'm going next. One change I've made though is to switch to Nullable<int>s for my IDs. I originally created this domain set in .Net 1.1 so that really wasn't a possibility. But now that I can, it can become a nice way to track new domain objects that must be persisted. This brings up a whole entire ball of scariness I haven't yet covered, how to track the dirty state of an Domain object, let me count the ways. First and foremost let me say that this is the sole potential benefit that I see in using DataSets instead of Domain objects, but it's not worth it by any means.

Handling the notion of a Dirty object, is a touchy one topic, both because it can provide a fair number of challenges, and because there are so many preferred patterns to use. However generally I tend to cheat here especially when it comes to making any decision about whether to persist/update/delete a domain object I rely solely on the BLL to make the call. Because I generally try to follow a pattern where any UI, or API that can create or modify data has absolutely no contact with domain objects, I can push any state logic out of the domain layer allowing for a very simple model. I can't say if this is the best model, only that I like idea that a least one application layer can be very simple.

So without further ado here's the ContactInfo Class and its constituents:

public class ContactInfo
{
public int? ContactInfoID { get; set; }
public List<PhoneNumber> PhoneNumbers { get; set; }
public List<Address> Addresses { get; set; }
public List<EmailAddress> EmailAddresses { get; set; }

public ContactInfo()
{
}

public ContactInfo(int? contactInfoID, List<PhoneNumber> phoneNumbers, List<Address> addresses, List<EmailAddress> emailAddresses)
{
this.ContactInfoID = contactInfoID;
this.PhoneNumbers = phoneNumbers;
this.Addresses = addresses;
this.EmailAddresses = emailAddresses;
}
}
public class EmailAddress
{
public int? AddressID { get; set; }
public string Address { get; set; }
public Status Status { get; set; }
public int Order { get; set; }

public EmailAddress()
{
}

public EmailAddress(int? addressID, string address, Status status, int order)
{
this.AddressID = addressID;
this.Address = address;
this.Status = status;
this.Order = order;
}
}

public class PhoneNumber
{
public int? PhoneNumberID { get; set; }
public string Number { get; set; }
public PhoneNumberType PhoneNumberType { get; set; }

public PhoneNumber()
{
}

public PhoneNumber(int? phoneNumberID, string number, PhoneNumberType phoneNumberType)
{
this.PhoneNumberID = phoneNumberID;
this.Number = number;
this.PhoneNumberType = phoneNumberType;
}
}
public class Address
{
public int? AddressID { get; set; }
public AddressType AddressType { get; set; }
public string Street { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Zip { get; set; }

public Address()
{
}

public Address(int? addressID,
AddressType addressType,
string street,
string city,
string state,
string zip)
{
this.AddressID = addressID;
this.AddressType = addressType;
this.Street = street;
this.City = city;
this.State = state;
this.Zip = zip;
}
}

That's it not too much there, but next we'll look at the Roles side of the Person Tree.

Okay one more distraction, although I'm not yet focusing on unit tests, I'm going to include some code that I often use to support my unit tests. This class is used to create a default instance of a complex object. With my current code base I don't have a lot of use for it, but I'd like to throw it out there as I know it will be useful to me later, and hopefully someone will be able to turn it into something much more useful.

Object Creator

public class DefaultObjectCreator<T>
{
public DefaultObjectCreator()
{
if (_propertyValues == null)
{
_propertyValues = new Hashtable();
}
_objectType = typeof(T);
}

public DefaultObjectCreator<T> CreateObject()
{
Assembly asm = Assembly.GetAssembly(_objectType);

List<object> args = new List<object>();
ConstructorInfo ctor = selectConstructor(_objectType);
if (null == ctor)
{
throw new ApplicationException("Could not match provided parameters to any Constructor");
}

foreach (ParameterInfo pi in ctor.GetParameters())
{
if (_propertyValues.ContainsKey(pi.Name))
{
args.Add(_propertyValues[pi.Name]);
}
else
{
args.Add(getDefaultTypeValue(pi.ParameterType));
}
}
_createdObject = (T)asm.CreateInstance(_objectType.FullName, true, BindingFlags.CreateInstance, null, args.ToArray(), null, null);

return this;
}

public DefaultObjectCreator<T> SetValue(string paramName, object value)
{
if (null == _createdObject)
{
_propertyValues[paramName] = value;
return this;
}
foreach (PropertyInfo pi in _objectType.GetProperties())
{
if (pi.Name.ToLower() == paramName.ToLower())
{
pi.SetValue(_createdObject, value, null);
return this;
}
}

foreach (FieldInfo fi in _objectType.GetFields())
{
if (fi.Name.ToLower() == paramName.ToLower())
{
fi.SetValue(_createdObject, value);
return this;
}
}

throw new ApplicationException(string.Format("Could not find property [{0}]", paramName));
}

public T GetObject()
{
if (null == _createdObject)
{
CreateObject();
}
return _createdObject;
}

private ConstructorInfo selectConstructor(Type objectType)
{
ConstructorInfo[] ctors = objectType.GetConstructors();

if (_propertyValues.Count == 0)
{
foreach (ConstructorInfo ctor in ctors)
{
if (ctor.GetParameters().Length == 0)
{
return ctor;
}
}
return null;
}

foreach (ConstructorInfo ctor in ctors)
{
if (ctor.GetParameters().Length < _propertyValues.Count)
{
continue;
}

bool found = false;
foreach (string paramName in _propertyValues.Keys)
{
foreach (ParameterInfo pi in ctor.GetParameters())
{
if (pi.Name.ToLower() == paramName.ToLower())
{
found = true;
break;
}
}
if (!found)
{
continue;
}
}
if (found)
{
return ctor;
}
}
return null;
}

private object getDefaultTypeValue(Type paramType)
{
if (paramType == typeof(bool))
{
return false;
}
if (paramType == typeof(DateTime))
{
return DateTime.MinValue;
}
if (paramType.IsValueType)
{
if (paramType.IsEnum)
{
return Enum.GetValues(paramType).GetValue(0);
}
else if (paramType.IsPrimitive)
{
return 0;
}
return createDefaultObject(paramType);

}
return null;
}

private object createDefaultObject(Type objectType)
{

Assembly asm = Assembly.GetAssembly(objectType);

List<object> args = new List<object>();
ConstructorInfo[] ctors = objectType.GetConstructors();

foreach (ParameterInfo pi in ctors[0].GetParameters())
{
args.Add(getDefaultTypeValue(pi.ParameterType));
}
return asm.CreateInstance(objectType.FullName, true, BindingFlags.CreateInstance, null, args.ToArray(), null, null);
}

private Hashtable _propertyValues;
private T _createdObject;
private Type _objectType;
}

Domain in the Box Part 2

Jeff Mayeur — Fri, 26 Oct 2007 05:36:43 GMT

*** Note I'm doing this post series using Orcas Beta2. So most of my code samples will be using whatever new baked in goodness I can garner from new VS. So far I'm really amazed with this release of VS 2008, aside from awesome JavaScript Intellisense, and a generally lighter, faster feel, the big thing for me is that the 2 Deal Breaker issues I've had with the VS Unit Testing facilities have been fixed. As A long time TestDriven.Net user, It was an absolute requirement to have a right click Run Tests, that would either execute a full TestFixture or single Test based on Context. Second was the ability to double click on the Error output and go straight to the line of Code that barfed. Glory be, they are both fixed (I always thought of them as bugs, not missing features), and I now am sold on the VS way, I am not worthy…

The first part of the Plebian U domain I want to work through is the "person." I want to see if it's possible to encapsulate the full range of Employees and Students into a single object. I'm pursing this for my model as for the most part employees do not differ from students until the business logic layer. Sure employees get a salary or wage, and students pay tuition, but those are either actions of the University or students, not attributes of a person.

There are differences to be sure, but I think that I can encapsulate those within the bounds of a Role object. This allows me to define a person who has 0-n Roles, and not have to maintain separate objects to represent the same actual person. Another key constraint I'm placing on myself is that I'm not going to be using Interfaces. This is partly to help maintain as simple of a structure as possible, and partly because I'm not worried about things like lazy loading or late binding. In general those are very useful considerations for a large application, but my overriding principle here is to have something I can very quickly customize to my current needs, without getting hung up on things like Versioning or configuration headaches that go hand in hand with those wonderful runtime typed domains.

So I'm going to start by trying to identify everything that I think all employees and students have in common:

Names – First, Last and Middle<opt>
Date Of Birth
Unique Id – something the student/employee can use on forms (often this is an SSN, but I'm thinking more generic)
Status – Active, Inactive or Current/Former, I see the roll object distinguishing Full-Time or Part-Time
Addresses – Mailing, Home, Billing, Emergency, other,
Phone-Numbers – Residence, Cell, Work, Emergency
Email Addresses – Personal, Work, Emergency

What about the differences, like the students' grades, or class schedule, or a professor's class schedule or Start Date? Those are all really just other Domain objects. Employees will have an EmployeeRecord, and students will have things like an EnrollmentRecord, CurrentSchedule, and Transcript. By keeping things simple like this I'm getting at least 2 benefits, first is the ability to have my domain follow a reasonable pattern of normalization, and second Flexibility. If I create a Person with Roles, and Contact info, and basic Bio info, I can use that person object in an application for say a Gym. A person really is just a person, and it's useful not to clutter the domain with specifics that are not really necessary. It should be the Data not the format that tells us what we need.

Say I was making an application for an auto dealer. One of the objects I certainly have is a Car. It wouldn't make much sense to track something like "SellerID" as a property of the Car, it's totally unrelated. The same applies to our Person. A Person can do and posses many things, but neither the Actions, nor the Possession are actual properties of the Person.

One thing I've done thought is decided that I want to encapsulate a Person's Addresses, Phone-Numbers and Email Address as ContactInfo. It's a natural division, partly following the idea above, and partly violating it. Since the U cannot have a Person without some ability to contact them, it's fair to make it a property of the Person. Yet as both a nod to flexibility and separation of Domains, I see benefit in pulling it off as its own group. I may be totally wrong about this, but here's how I see my person domain object.

public class Person<T>
{
public int PersonID { get; set; }
public PersonReadableID<T> ReadableID { get; set; }
public Status Status { get; set; }
public List<PersonRole> Roles { get; set; }
public ContactInfo ContactInfo { get; set; }
public string FirstName { get; set; }
public string MiddleName { get; set; }
public string LastName { get; set; }
public DateTime? BirthDate { get; set; }
}

Some things to note: Status is an Enum; PersonReadableID<T> will likely die an untimely death, I'm looking for a way to give a person a unique ID like an SSN, that we can persist with the person Record, and this gets me that for now, but I don't like it too much; List<PersonRole> is a placeholder, I haven't gotten to Roles yet, but I know I need them; ContactInfo is also mostly just a stub, but here's a look at where I think I'm going.

public class ContactInfo
{
public int ContactInfoID { get; set; }
public List<PhoneNumber> PhoneNumbers { get; set; }
public List<Address> Address { get; set; }
}
public class PhoneNumber
{
public int PhoneNumberID { get; set; }
public string Number { get; set; }
public PhoneNumberType PhoneNumberType { get; set; }
}
public class Address
{
public int AddressID { get; set; }
public AddressType AddressType { get; set; }
public string Street { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Zip { get; set; }
}

With the Contact Info I'm not sure how I want to enforce grouping. IE should an Emergency Phone-Number and Address be treated as a single unit, or should it be the responsibility of the BLL to extract that info on demand, but that's for a later post, I've got some code, and some unit tests (won't bother posting most of those as they're very plain at this point).

Domain in the Box Part 1

Jeff Mayeur — Thu, 25 Oct 2007 05:14:35 GMT

This post series is going to cover the creation of a fairly simple creation of a set of Domain objects to cover the needs of a fictional Plebian University. The goal will be to create a set of Domain objects that will service a "tracking system" that encapsulates the management of people and facilities for this university. The set of posts will be centered on the Domain objects but we can't really fully develop those objects without knowing a little about how we want to approach persistence and how we want to handle business logic.

Sure there are hundreds of examples of domain object creation, so why bother posting on it? First because I need to update my canned library. Second because I want to take a deeper look at some of the stuff coming up in .Net 3.5. Third because a lot of the examples use the Customer/Order/OrderDetail problem set, and while that set is rich, I think there's a little more complexity to be had in the classification of a scholastic institution. And lastly, well because the point of a blog isn't necessarily always to have all the answers, rather sometimes it's about testing yourself. Key to that notion is that I've always been a Web-Developer, at least at heart, and one of the big implications of that is the tendency to start the design process from the point of view of what the UI can possibly do. In this case I really am going to try to stick to a true domain level mapping of my problem set, and not get bogged down to heavily in how I'm going to deal with the problems from the UI.

One of the problems I like that the scholastic model presents is how to handle professors who are students, or students that are employees. From a persistence (DB) level it's pretty easy to see a Person store, and a PersonRole store that allows multiple Roles per Person. In the domain level I can choose to split these out into firm types, or more closely model the persistence layer waiting until the business object layer to make any distinction. However we decided to cover that ground I want to make sure I can explain my reasons in plain English such that my fictional End Users will be able to comprehend both the correctness and implications of my choices.

Another good problem is the idea of forced generalization. Consider that a common scenario in our fictional university is the temporary repurposing of facilities. Say a classroom that is being used for chair storage. I need to be able to represent this room both as a classroom and as a storage room, so something like the Roles classification system seems logical, but what about rooms that are multipurpose such as storage and rehearsal space. Or facilities that need to be reclassified solely on the basis of its current occupant like a yoga studio that's also a creative writing classroom and Daycare playroom. How are we going to represent this type of flexibility while still providing a meaningful representation of the universities facilities, what's the role of the Domain and what's really a Business Logic Layer decision, these are the types of questions I want to answer.

The other part of this series of posts is to help layout and examine the evolution of requirements. Anyone with at least one project under their belt will know the humor found in the schedule marker "Requirements Complete". To the best of my knowledge, there has never been nor ever will be a "requirements complete" state for any business software project. For this post series I want to have an informal approach to requirements. There'll be some high level requirements, but in general we won't flush them out until we're in a specific problem space. Also the requirements will be focused on the Application level and not on the Domain. Partly that's to make their expansion somewhat realistic, and partly to allow me to be vague in laying them out.

Requirements:

The final Application needs to track all students and staff, full-time and part-time, exempt and non-exempt, current and former.
The final Application needs to track all Colleges, both enrollment, usage of facilities, staff, and students who's major's fall into that college and students fulfilling requirements
The final Application needs to track all facilities, both buildings and grounds.
The final Application needs to track on campus student housing needs.

Okay seems simple enough. The plan is to break off each Domain object by itself, with some exceptions like Person and PersonRole type groupings. Hopefully when this is done there'll be a nice set of domain objects we can use for future sample projects. And the next set of posts will be consuming these objects in Business Logic Layer.