So in the past, the website I work on has relied on a single layer architectural that mixes data access directly with application and view code. I’ve recently convinced the team of the advantages of implementing a Data Access Service Layer (API); Especially with recent talk of horizontal scaling (native mobile applications, etc).
Right now the implementation that comes to mind is involves using Entity Framework to map the database to Data Contract classes which the client will request using a WCF service.
I’ve used this approach in the past on a smaller scale but now with the scope of a large collection of data objects, each with numerous criteria they may be queried off, I’m having problems envisioning how to structure the API.
Example List of data classes:
- Product
- Merchant
- Brand
- Taxonomy
- Coupon
- User
- Reviews
- Questions
- Answers
- Etc
(hopefully the way these objects are related is obvious enough to make my points)
Service Requirements
- Service must be language independent (.net, php, java, objective c)
- Pattern must allow for several different datasources acting as one api (say our users are stored in a MSSQL server, our Reviews system in MySQL, and our products come from an XML feed)
- Must be able to implement object caching from the API side
Each of these data objects essentially needs to be queryable based on several of it’s columns (to either return a single object or a collection). While I could write a new API method for each of the different scenarios, I’m thinking there must a more elegant way of doing this.
Example Requests:
- Get single Product by id.
- Get list of products from a specific merchant, brand, or taxonomy ordered by ‘create date’, ‘price’, or ‘percent-off’.
- Get all Reviews Submitted by a User
- Get all Reviews of a Product
- …
In my research I came across this MSDN Article outlining several standard approaches for creating an API. I would be interested in hearing advantages and disadvantages of each, as well as which approach seems to fit the model I’ve described above best.
Essentially there are many patterns that do exactly this.
UI Layer => Data Access layer => Core layer
EF used in DAL, The model and Logic in CORE.
Core declares interfaces and models for Other other layers to use.
Do some reading on “Repository pattern” Unit of Work Pattern” Inversion of Control optional extra.
If you are prepared to put 50USD on the table, there are some excellent video tutorials on http://Pluralsight.com to walk you through these concepts. Even sample apps etc. The 50USD is well spent in my view (1 month subscription).
I particular recommend the video on pluralsight by Julie Lerman on EF and Enterprise architecture.
Some very good tips there.
I use such a pattern. And it works very well.