A new project on my table at the client place, a new opportunity to make it differently and embracing the change. An old, very old style of DataLayer is currently used and implemented, old fashion I can say, like it was done in the old age of .Net 1.0… DAL generated by a code generator with Business / DAL object fully spread anywhere in the universe with some SQL statement randomly hard-coded in every corner controls events.
The step is big, from 2002, when .net 1.0 was officially released, to now… 12 years have passed. So many things have changed since… but unfortunately, Microsoft.VisualBasic reference still persists for some vb.net developer…
Ok, more seriously, this opportunity to propose something more fresh and hype to the client is there. I taken times during the day to find more interesting fact, opinions and practices about what I really care of: The abstraction of the Business layer and the Data Layers.
To play fair, the subject was to find the current trends on the separation of these two layers with the usage of Entity Framework or some others kind of ORM, without any kind of dependencies from Business Layer on the ORM. The response seems to be the implementation of POCO models, the usage of Repository Pattern and Unit of Work.
Here some links from where I had started
- Entity Framework 5 with auto mapper and repository pattern
- Entity Framework 4 POCO, Repository and Specification Pattern
- ASynchronous Repository Pattern with entity framework 6
- Generic Unit of Work & (Extensible) Repositories Framework
- Models (POCO), Entity Framework and Data Patterns
- Repositories On Top UnitOfWork Are Not a Good Idea
- Repository is the new singleton
- Build Reusable Testable Commands Part 1
- Build Reusable Testable Queries Part 1
- Build Reusable Testable Queries Part 2
- Favor query objects over repositories