A very important question recently crossed my inbox, and it essentially asked:
“Can you design and build Enterprise-grade n-tier applications with OpenAccess? Or does it force you violate principles of good multi-tier application design to make the ORM features work?”
It was a great question and I was surprised to find that there is not more info in the online docs to address this. So, to help everyone benefit from this question’s answer, here are some details about building n-tier applications with OpenAccess.
WHAT DOES GOOD N-TIER ARCHITECTURE LOOK LIKE WITH OPENACCESS?
Let me preface this discussion by saying there is no “absolute” right or wrong way to architect an application. The approach highlighted here is just one way that will help you build applications that use OpenAccess with clean separation of concerns and respect for principles of multi-tiered application design. With that out of the way, a “typical” multi-tier app built with OpenAccess should look something like this:
- Entities (or Model): Contains your persistent classes; Project is “OpenAccess Enabled” to define Persistent Classes (PCs) and includes DB mapping info in the config file. The persistent classes in this project can be created via the Forward or Reverse Mapping OpenAccess wizards.
- Data Layer (Optional): Optional, in my opinion, since the actual “data plumbing” will be handled “automatically” inside OA. I prefer to skip this layer, but it can be used for storing your LINQ queries and returning data to your business layer, if desired (and if you don’t want LINQ in your business layer).
- Business Layer: Provides “Repository” (or “Manager”) classes that define operations on model (such as FindAll, FindById, Insert, etc.). Acquires ObjectScope used to manipulate objects in the database. “OA Enabled” to consume PCs, which adds ObjectScopeProvider to project (but does not add mapping info to project)
- Service Layer (Optional): To build an app that is ready for client-oriented technology (like Silverlight and ASP.NET AJAX 4.0), it is usually smart to build a service layer on top of your business logic. The service layer consumes your business layer “data manager” classes and exposes the operations as service endpoints.
- Presentation Layer: Consumes business layer repositories (if no service layer) or consumes services. The presentation layer can be completely ignorant of OpenAccess and it has no need to be “OA Enabled.”
The project linking would look some like this:
Presentation consumes Services consumes Business consumes Data (if present) consumes Model
The only time you might “break” this direct inheritance tree is if you want to re-use your model classes in your other tiers for easier data binding (i.e. I want to bind to return a List<ModelType> vs. some intermediate class type). Still, in that case, you’re only using the class model for binding- you’re not doing any data access outside of your data access tier. Here is the same architecture in picture:
WHAT PROJECTS NEED TO BE OPENACCESS ENABLED?
One of the bigger points of confusion when it comes to using OpenAccess in n-tier applications seems to be which layers require you to run the “OpenAccess Enable” wizards. To be clear, there are two types of OpenAccess enabling provided by the wizard in Visual Studio:
1. Project Defines Persistent Classes: Adds configuration info to App.Config containing DB mappings, Adds refs to OA assemblies
2. Project Consumes Persistent Classes/Connects to DB: Adds references to OA assemblies, Adds ObjectScopeProvider class (for help managing ObjectScope), Adds connection info to project configuration file
In general, the only layers that need OA enabling are your model (where your persistent classes are defined) and your Data or Business layer (or whichever layer you’re using to actually execute queries against the DB).Other layers, like your Presentation layer, do not need to be enabled. And in all cases, when you run the wizard, you’re not adding references to other projects in your solution- just to the OpenAccess assemblies.
I hope that helps clear-up the general approach to using OpenAccess to build n-tier applications. OpenAccess is definitely powerful enough and flexible enough to handle Enterprise architectures, so it’s usually just a matter of understanding how and not if OpenAccess can do what you want.