Designing an Object Model Layer

The Object Model is a must layer in every application. This article explains how to implement an OM for your application.

Introduction

Every major application contains an object model. You can take, for example, the Office object model or the SharePoint object model. When developing an application, there are always some classes, interfaces, enumerations etc., that are spread all over the code. There are always some more classes to add or interfaces to implement. If those types are not located in a centered location, it is very hard to find them, maintain them, and use them. It is important to try to get these types into a known location. I will start by an example.

As a team leader, I had to assign some tasks to my developers. Each one provided me a class diagram. After reviewing and approving those, they continued to the development stage. That’s all fine, but what happens when a developer needs to use a class definition that another developer created? Or, implement an interface? If it is in the same assembly, he will add a using statement for reaching the object declaration, for example:

using EnterpriseServices.Framework.Services;

If it is not in the same assembly, he is really out of luck. He can add a reference to the assembly:

However, the right thing to do is to refactor the code and relocate the object declaration. In this article, I will discuss about my view on how to handle the above mentioned situations by creating an appropriate OM (object model).

Starting with an example

I will try to keep this example as simple as possible. Suppose there are two developers, and let’s give them names A and B (nice names). Say, they both had been given an assignment. A has to create a class User that contains the first name and last name, and B has to create a CodeProjectUser that contains the first name, last name, user name, and password. For the purpose of augmenting, let's say that the developers did not know about each other’s assignment. So here is what A did:

In the next team meeting, A and B realize that they both created the same IUser interface and the User class. There are now two options they can choose from. They can argue who should keep their code, or they can both refactor it by placing the shared code into a shared location. This shared location is the Object Model.

The OM

What is an OM? In my point of view, the OM is a logical layer that contains definitions for common types. These common types can be used throughout the application or can be used by other applications. When thinking about object model design, we always need to think outside the box. In other words, we must consider a situation where the model needs to be extended. For example:

All extensions to the OM use the base as reference. Usually, the base object model is located in a deferent assembly than its extensions; however, this is not a requirement. So, say you have developed an application or a framework (core, shell, etc.), you must define a location where all the shared types must sit in. This is because you would like to reference those types from anywhere in the application. That means that the OM must sit in a “God DLL” to which every assembly can add a reference, but it can not have any reference to others. By doing that, you can ensure that there will be no circular dependency. If your application does not include an OM, it is my recommendation that you should define one.

What goes inside the OM

I will try to give you some basic understanding for deciding what should go inside an OM and what can be left out. First, you must remember that the OM is actually an API to an application. And thus, you will not want to add everything to this layer. The OM can contain classes, interfaces, enumerations, and other types. If the types need to be recognized in several assemblies, or they should be an API to other applications, it is a good chance that they belong in the OM. If the type should not be recognized through all the layers, you need to think about extending the object model as explained in the previous section.

Summary

The object model is a must layer in every application. Most of you probably have used it in some form; however, some of you have not realized the importance of this layer or its existence. I hope that by reading this article, you are now able to understand what stands behind the OM. Maybe from now on, when you design an application, you will keep in the back of your mind the need for a good object model layer.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

hi Kolbis
Me as graduation student, find lot from the concept u describe. I mostly use the same concept in my code, but unfortunatly i was not able to answer why i m doing always like, because i donot have the concept in theory for OM, which now i have with my belt. So now I can better doit, no no not doit instead, play with it. hahhaha
Thanks.
Regards
Rizwan Yasin

I was under the impression that something is either an abstraction or it is not. I didn't realize there was another form of abstraction.

There are different levels of abstraction. Marc -> male -> human -> life form.

A "message" is very abstract but easily described. What I've found is that, when an object model attempts to model concrete entities, it becomes rigid and inflexible to change, because concrete entities tend to change over time. A model of horse drawn buggies would have a difficult time in today's world of jets, shuttlecraft, and turbocharged cars. But an abstraction, like "vehicle", would be more flexible.

However, since most programmers are taught that OOD means that you start with vehicle and derive your specialized classes, the resulting application ends up being rigid. This is where I think OOD fails. It works great when you stay within the realm of the abstract, and it starts to box you into a corner when you use it to specialize into the concrete.

I think you're on to something - the problem with OOD is that it is deceptively simple - while it's easy to create base or abstract objects that should represent the abstraction, and derive concrete examples from that, in practice, most OO programmers merely create an object model that works for their current application and for nothing else.

OOD is at its heart much more complex and creating a truely well-designed and extensible object framework is very, very, very hard. There are people who dedicate the whole of their careers to studying the issues involved.

In my own programming, I try to do two things:

1. Lay out as few concrete requirements and/or object properties as possible - this way, my derived objects do what I want them to do, and not what the abstraction limits them to (in your own example - a vehicle is an abstract concept; you wouldn't want to limit a 'vehicle' to one that only moves people, for example).

2. More importantly, I try to consider the way *I* conceptualize the world, in its most basic objects - and then write my objects reflecting that framework (because all humans conceptualize the world in almost the same way - it makes the code inherently intuitive to anyone reading it).

Hi Marc,
Have you read the Enterprise Patterns by Martin Fowler?
In his book he indicates that there are two main models that you can use.
The first one is Domain model which is the OM and Table model that is the DataSet and DataTable concept.
In my opinion (and Martin's also) the Domain model is a must concept in each application! And I would not have it any other way.