Click here to Skip to main content
Click here to Skip to main content

Designing an Object Model Layer

, 28 Mar 2006
Rate this:
Please Sign up or sign in to vote.
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:

Sample Image

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:

Sample Image

He creates an IUser interface:

public interface IUser
{
    string FirstName
    { 
        get;
        set;
    }

    string LastName
    {
        get;
        set;
    }
}

He then creates a User class that implement IUser:

public class User : IUser
{
    string _fname;
    string _lname;

    public User()
    {
    }

    public User(string firstName, string lastName)
    {
        _fname = firstName;
        _lname = lastName;
    }
    
    public string FirstName
    {
        get { return _fname; }
        set { _fname = value; }
    }

    public string LastName
    {
        get { return _lname; }
        set { _lname = value; }
    }
}

B being a good OOP programmer and who did not know about the work A did, designed something similar:

Sample Image

He creates a CodeProjectUser that extends the User class:

public class CodeProjectUser : User
{
    string _userName;
    string _password;

    public CodeProjectUser()
        : base()
    {
    }

    public CodeProjectUser(string firstName, string lastName)
        : base(firstName, lastName)
    {
    }

    public string UserName
    {
        get { return _userName; }
        set { _userName = value; }
    }

    public string Password
    {
        get { return _password; }
        set { _password = value; }
    }
}

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.

Sample Image

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:

Sample Image

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.

A list of licenses authors might use can be found here

Share

About the Author

Guy Kolbis
Web Developer
Israel Israel
Guy Kolbis is a system architect and technology consultent.
Instrested in c#, asp.net, design patterns and tennis.
B.S in computer sience.
7 years experience in .net.

Comments and Discussions

 
GeneralReally Smart!!!!!!!!!!! PinmemberRizwan Yasin6-Aug-07 19:49 
GeneralRe: Really Smart!!!!!!!!!!! PinmemberGuy Kolbis13-Nov-07 7:11 
GeneralActually PinprotectorMarc Clifton28-Mar-06 12:15 
GeneralRe: Actually Pinmemberyafan28-Mar-06 14:05 
GeneralRe: Actually PinprotectorMarc Clifton28-Mar-06 15:22 
yafan wrote:
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.
 
Marc
 
Pensieve
Functional Entanglement vs. Code Entanglement
Static Classes Make For Rigid Architectures
 
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
GeneralRe: Actually PinmemberPatrick Sears3-Apr-06 8:15 
GeneralRe: Actually Pinmemberkolbis29-Mar-06 22:58 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140827.1 | Last Updated 28 Mar 2006
Article Copyright 2006 by Guy Kolbis
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid