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:
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.
@toddanglin on Twitter