02 Jun 11 Building An Object Model And Access Layer in Asp.NET
In an ASP.net application, the object model is going to be the lion's share of your code, so creating a well-constructed object model is essential to building a good Asp.net application. What goes into an object model? How do you build one?
For starts building an object model is no different from building an class hierarchy. You'll follow the same rough design that I described in my series of posts about building a class hierarchy. However, your object model may not fit into a simple three-tiered system like I discussed. Complex object models, which tend to follow complex applications, required multiple packages (dll's). Those packages, which, as a side note, cannot have circular references, can interact in ways that do follow a simply tiered system. However, the overall design of your model should still seek to separate mechanism from policy and to abstract as much as possible into generics.
An object model is not always a basic tiered system, so how is the model broken down? Each object model is different, because the needs of each application different. However, there are some similarities. Every object model has interfaces, classes, and abstract class on which it depends upon heavily. These should all be in one package. Why? Robert Martin, in his object-oriented design work, states that "packages" should depend towards stability. That packages should only depend upon those that are less likely to change. Core elements of code rarely change outside of the early stages of a product, so they should all be in one package upon which all others depend.
What goes into that core package? For starters, any class that is used in every aspect of you object model has to be in the core package. The interfaces for key parts of the packages are also included. Generics for aspects of the object model that customized in multiple packages are included as well. In short, the core package provides not only a higher level policy and generic layer, but a collection often-used, tried-and-true classes as well.
What other packages should an object model have? You're going to access to a database and a way to get data into and out of your objects, so that functionality should be in a package. This package will reference and build upon the core package. The other packages will use this package to handle transporting data back and forth from the database. There are number of tutorials on how to achieve this. At later date, I'll write an article that describes how to create a framework to achieve this, but, for now, trolling the internet and you can find a suitable one.
You've got a core package and a package to transport data between a database and your objects, but what about the objects? The next package contains the objects that represent the object's within your application, their access functionality and logic. A separate business logic package could be created on which this package would depend, but that may be overkill for now. That option exist of the if the data model package starts to bloat. Anyway, here is where you would map out the class hierarchy like I described in my previous posts. This package is every likely to change and/or be extended, so separating policy from mechanism is hugely important within this package. I'll post something at a later date that goes specifically into creating a data model.
I discussed the possible of separating out business logic into a separate package. Well, there one more wrinkle that may or may not be necessary: access control. Depending upon the nature of your system, you may not need access control, but, if you do, access control is intimately tied into both the data model and the access package. Access control can be tied into the access package. There's nothing inappropriate about doing that. However, access control can morph into sizable piece of code on its own. Separating it out into its own package may make your code more maintainable. Access control is tricky, so I'd stay from it in the short term. At a later date, I'll post article that describes creating an access control system.
I hope that this gives you a good sense of what an object model and access layer look like. Some of the details are missing, but I plan to fill them in later. Building the object model and access layer are the hard part. If you can get that up and running, then the rest of the application is easier.
My posts about designing a class hierarchy:
