A place where we write words Ignition Blog

Welcome to the Ignition Development blog, where we talk about a wide range of technical and non-technical topics.

One Layer to Rule them All

Posted on Thursday, April 3, 2014 6:41 PM, filed under Technical · Team

As we were moving from the age of hand crafted stored procedures and inline SQL into the new age of OR-mappers, we had a few different choices to make in terms of which product to go with. After a period of research we eventually decided on staying away from third party applications as much as possible and relied on Microsoft’s Entity Framework (as Linq2SQL was fading away at that point).

Over the many years I’ve spent developing applications, I’ve always managed to end up in the role where I try to improve performance where ever it’s possible, and about 90% of the time the most gain is achieved by improving an application’s interaction with the database.

Bearing this in mind, I set out to create a simple platform or wrapper of the functionality to streamline the methods for retrieving and saving data. Seeing how it’s always a goal to have as maintainable code as possible, I wanted to enable developers to make the easiest way to access data the most maintainable and readable way as well, as well as taking away some of the complexities so people don’t necessarily need to know 100% what’s going on under the hood, just that data gets saved/retrieved from the database.

After a bit of development, the internally labeled “JanDAL” project was born, and it has simplified the initial setup of a data-layer in all projects where it’s been used immensely. Shortly after it was extended to include methods for caching, ensuring even better performance without the need for hand-crafted caching methods.

I’ve kept refining and optimizing this over the years based on feedback and real world experience, and we currently have quite a few applications running in production environments based exclusively on this layer for its data-retrieval and storage strategy, including all SFF sites.

As the latest version of Entity Framework shipped, I adapted the layer to the work with both the old and new versions and decided it was time to send it off into the world so others might take advantage of this, and bravely put together a NuGet package with the data layer, as well as other tools we frequently use in our projects.

If you’re a developer and want to take advantage of this, you can download the library Mijan DataLayer from the NuGet package manager, and refer to the overview and cache information at the personal site at http://janheggernes.net/post/mijan-core-datalayer-nuget-package-overview and the cache overview at http://janheggernes.net/post/mijan-core-datalayer-quick-cache-samples along with the service framework we use at http://janheggernes.net/post/mijan-core-service-overview

If you’re a business who struggles with performance in your .NET applications, get in touch with us for help with performance.


- Jan


# re: One Layer to Rule them All

Posted by Hrvoje Hudoletnjak on 4/3/2014 9:26 PM

What are benefits in abstracting DbContext to some DAL<UoW> class, and doing the save .Where(...), .Save... stuff again, but just over the new interface?
Form EF 4.2+ we can easily mock DbContext, so unit testing is not an issue any more. Also, DbContext API is quite nice finally, so we don't need some kind of Facade pattern there.

I saw many examples of Repository<>/DAL<> abstractions, without any real value to architecture and design, which are doing basic CRUD stuff but just over few more layers. And non of them are implementing real Aggregate Roots, bounded contexts and transaction scope management (DDD concepts), that would justify the complexity.

Maybe I misunderstood how this framework works, but just sharing some of my thoughts...

# re: One Layer to Rule them All

Posted by Jan Heggernes on 4/5/2014 3:53 PM

Hrvoje, these are very valid questions! One of the primary drivers behind having a facade pattern is essentially real-world experience with working in teams with people who aren't as focused on architecture and design and just want to make their own items/bugs work asap. Upon realizing that teaching certain developers to do anything that made their workday more complex would last a couple of day at most, I instead worked on having a "good enough" approach that would actually ease their workday while not driving me back to the point where I had nightmares about people ravaging the databases and codebases I swore to protect.

I saw early on while exposing ObjectContext that developers were using this in a manner that would unintentionally leave the context hanging forever, excessive amounts of "this object belongs to another context" and some very strange reflection-attempts that could drive any person to drink! So, the reasoning here is to give developers something easy enough to use that solves these common issues, and hides some of the more "complex" functionality that is powerful enough to be abused to reduce potential madness in any given solution.

In a perfect world one wouldn't need to do this at all, but this really eases the pain when trying to ensure at least bits of sanity managing code coming from certain unnamed countries where code conventions, design and architecture are more than literary foreign concepts. I know if we exposed DbContext in some of our projects, there'd only be a matter of time before some clever developer found that everything was easy now cause he found dbc.Database.ExecuteSql(). Given the questions you've raised, it seems like you don't have to worry much about this package - as I don't think you're the target audience for this! :)

Would you like to post a comment?

Post title
Your name
Your email (optional)  
Website (optional)

What do you want to say?


Please add 4 and 8 and type the answer here: