separation of concerns

AppBoot Library

AppBoot is a generic .NET application bootstrapper, we at iQuarc, have put on GitHub a while ago. It started few years back when we were about to begin developing a large enterprise application. Back then, we wanted to use the Unity Container for dependency injection, but we liked the way

Benefits of Data Access Encapsulation

We all know that achieving a good Separation of Concerns is good, because it increases the maintainability and it reduces the cost of changing our code. This pays off big time in long running projects, with large code bases where changing code is a big part of the coding activity

Using ReSharper for Assembly References Diagrams

A few posts back I talked about how we can use the assembly references to enforce consistency and separation of concerns (here and here are the old posts). I argue there that if we derive from the architecture the assemblies of our application, the kind of code (responsibility) each one

Enforce Consistency with Assembly References

In this post I’ll describe some key aspects that I consider when designing the assemblies that build a system. When we structure our code into assemblies (generally named binaries, libraries or packages in other platforms than .NET) we are reasoning about three main things: * Deployment: different assemblies are deployed

Separating Data Access Concern

In our days most of the applications that have a relational database as storage, use an ORM to access the data. The ORM (Entity Framework, Hibernate, etc.) does most of the data access implementation. Many of them have a modern API for querying data and for creating sessions of editing