design

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

Data Isolation and Sharing in a Multitenant System - Part 3

This is the last part of the "Data Isolation and Sharing in a Multitenant System" article, which is also a continuation of my post that outlines the benefits of a well encapsulated data access. In this post, we'll look in detail at the implementation of the

Data Isolation and Sharing in a Multitenant System - Part 2

This post is the second part of the article that shows how a well encapsulated data access implementation can play a key role in implementing a multitenant application. It is also a continuation of my post that outlines the additional benefits such a data access implementation may bring, multitenancy being

Data Isolation and Sharing in a Multitenant System - Part 1

In the previous post I've shown few of the additional benefits a well encapsulated data access implementation brings. Implementing multitenancy is one of them. This article continues the previous, picks up the multitenancy context from there, and shows how we can address one of the most important design

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

DRY vs Coupling

While reviewing my previous post another great discussion, which may arise from paying attention to your references, came to my mind: Don’t Repeat Yourself (DRY) vs Coupling. Each time you add a new reference it means that you want to call the code from the other assembly, therefore you

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

Dependency Inversion and Assemblies References

In my last posts I have talked about using assembly references to preserve critical design aspects. In Enforce Consistency with Assemblies References I talk about how we can use references to outline the allowed dependencies in code and how to use a references diagram to discover code at wrong levels

Repository Implementations

In my previous post I have presented a way to separate your data access from the business logic, when a relational database is used. I have shown another implementation of the well-known Repository pattern. Since Martin Fowler described it in his book Patterns of Enterprise Application Architecture it became one

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

Disposable Instances Series

In the past few weeks I have published a set of four posts that deal with disposable instances. These posts describe in detail a working implementation that automatically disposes all the instances that are no longer needed, in a deterministic way. This solution works when we use Dependency Injection or

Disposing Instances when Using Inversion of Control

In the last few posts I have written about how to deal with IDisposable instances when using Dependency Injection. In the Who Disposes Your Repository I talk about the possibilities and challenges of disposing a repository which is injected. Then in the Extending Unity Container for IDisposable Instances (part 1

Extending Unity Container for IDisposable Instances (2nd approach)

In my previous blog post I detailed an approach of making the Unity Dependency Injection Container ț̦o automatically call Dispose() on all the IDisposable instances it builds and injects. The implementation described there, makes use of custom lifetime managers and it works fine for most of the cases except

Extending Unity Container for IDisposable Instances (1st approach)

A few weeks ago, in my blog post ‘Who Disposes Your Repository’ I wrote about the challenges of implementing an IDisposable repository, which takes full advantage of the deferred execution of the IQueryable and, which is being injected through Dependency Injection (DI) into the classes that need to read or

Who Disposes Your Repository

Recently, I’ve went again through the discussion of how the Repository Pattern works with Dependency Injection (DI) in one of the projects I’m involved in. Even if these patterns are around for a while and there are many examples on how to use them together, discussing some particular