How To Design Easily Testable Asp.Net Mvc Action Filters

By Mike on 16 May 2013

While Asp.Net Mvc is a much more test friendly framework compared to WebForms, some things are still complicated to test. Custom Action Filters are very common and naturally you want to test them too. But you still have to setup a whole chain of dependencies (the filterContext argument) even for trivial filters.

However, we can test things much easier, without the complicating setup. Let's say I want a filter that takes the id from the url, gets the user for that id and then cache it in HttpContext.Items. It looks something like this

public class MyFilter:IActionFilter
    {
        
        public void OnActionExecuting(ActionExecutingContext filterContext)
        {
            var repo = DependencyResolver.Current.GetService<IMyRepository>();
            int uid;
            if (!int.TryParse(filterContext.RouteData.GetRequiredString("id"),out uid))
            {
                filterContext.Result=new HttpNotFoundResult();
                return;
            }
            var user = repo.GetById(uid);
            if (user == null)
            {
                filterContext.Result = new HttpNotFoundResult();
                return;
            }
            filterContext.HttpContext.Items["user"] = user;
        }
        
     
        public void OnActionExecuted(ActionExecutedContext filterContext)
        {
            
        }
    }

While the behavior is quite simplistic look what I have to fake: the DependecyResolver, the RouteData and the HttpContext. Let's refactor it so that it's easily testable

public void OnActionExecuting(ActionExecutingContext filterContext)
        {
            var repo = DependencyResolver.Current.GetService<IMyRepository>();            
            var user = GetUser(repo, filterContext.RouteData.GetRequiredString("id"));
            filterContext.Result = CacheUser(user, filterContext.HttpContext.Items);                        
        }

        public User GetUser(IMyRepository repo, string id)
        {
            int uid;
            User user = null;
            if (int.TryParse(id, out uid))
            {
                user = repo.GetById(uid);                
            }
            return user;
        }

        public ActionResult CacheUser(User user, IDictionary cache)
        {
            if (user == null)
            {
                return new HttpNotFoundResult();
            }
            cache["user"] = user;
            return null;
        }

I've isolated the desired behavior in 2 public easily testable methods. With GetUser you can test what happens if the 'id' is or not a valid user id having only to mock IMyRepository. With CacheUser you can test what happens if the User is null or not. None of these methods depend on asp.net mvc so no need to fake all the ActionExecutingContext object. Better yet, the behavior can be used outside the action filter as well.

It's a trivial example because it's a simple technique: extract the actual behavior in one or more relevant methods which take only the dependencies they need. In this example we needed only the repository and an IDictionary. Very rarely you'll need HttpRequest or HttpContext as a dependency, usually you need only a property.

Here's another example. I want to allow access only to users with the email belonging to some domain.

public class DomainEmailAuth:AuthorizeAttribute
    {
        public string EmailDomain { get; set; }

        protected override bool AuthorizeCore(System.Web.HttpContextBase httpContext)
        {
            if (base.AuthorizeCore(httpContext))
            {
                var repo = DependencyResolver.Current.GetService<IUserServices>();
                return IsAuthorized(repo, httpContext.User.Identity.Name);
            }
            return false;
        }

        public bool IsAuthorized(IUserServices users,string username)
        {
            Email email = users.GetEmail(username);
            if (email != null)
            {
                if (email.BelongsToDomain(EmailDomain))
                {
                    return true;
                }
            }
            return false;
        }
    }

 The relevant behavior needs only the UserServices and the username in order to get the email and find out if it is allowed. It can be tested without caring about asp.net or the AuthorizeAttribute itself.

You Might Be Misusing The ORM

By Mike on 15 May 2013

ORMs are trendy these days and it's so rare when someone mentions DDD or Repository without saying ORM (actually Entity Framework or NHibernate, but ORMs are popular with dynamic languages as well). The issue is the ORM is viewed like a magic tool and everyone (especially people starting to learn programming) seems to consider they are the present and the future.

However, I think that people should be tempered a bit, as the use of ORM doesn't always simplify things, more often than not it actually complicates things.

First of all, what is an ORM, what is its purpose? An ORM bridges the gap between the Object Oriented mindset (in fairness, lots of 'OO' code is not even remotely object oriented, but that's another story) and the relational database. This means that ORMs make sense only with a relational database which are still very common but not as popular as they once were.

The truth is a lot of developers simply hate Sql or at least they don't like it very much. But with an ORM you can use a RDBMS without Sql! Instead of writing queries  you're just using objects. After all, it makes sense to say that a Category has a list of Posts, instead of the Post table having the foreign key category id. The ORM creates the illusion of a object oriented database without a trace of the Sql stuff (except the configuration part).

But here where things get interesting. The developer doesn't care about the relational database and sql because it can use the ORM, but many devs forget this tiny detail: by abstracting the RDBMS the ORM becomes itself the database. It doesn't matter that we don't write sql anymore and we use objects directly. Those objects represent the relational database tables.

In the case of CRUD apps, things are very simple as there are only data structures flying around. The minimum validation or some basic processing don't really change anything, we can't speak about a 'real' application with rich business logic. For this scenario the ORM is indeed a God sent tool. Incidentally, MANY examples and demos for ORMs are about this type of apps.

But we have the 'advanced' applications. Where there is rich business behavior or the querying performance matters or both. Let's take the 'easy' case where performance matters. An ORM has an overhead which affects speed. It simply can't match manual or data mapper performance. Even more troublesome is the sql generated by the ORM. Entity Framework for example, is infamous for the convoluted sql it generates.

But after all, an automated tool can't do very much, not in the case where you need to squize every ms of speed. For those cases you simply must have sql queries hand tweaked by an expert. And this means that one feature of the ORM goes away: abstraction of the database. The expert will write quite specific RDBMS sql, so changing the underlying db engine becomes cost prohibited. Hand tweaked also means that the ORM's own query language will be also ignored so, for this scenario the ORM just becomes an impediment. Of course, for very high reading performance chances are you're not using a RDBMS in the first place, so no ORM here either.

The most tricky issue with ORMs is when dealing with behavior rich applications. It's true that some applications start as CRUD and evolve in behavior rich so that's understandable why the app was designed the CRUD way where ORM is central to everyting. But when you know the app is not CRUD and you have business objects which models business concepts and processes, then the little detail that the ORM is the database matters a lot.

Because there is a mismatch between how a behavior rich business object looks and how the object that represents the database looks. A business object contains other business objects which can be entities or value objects. It's very complicated to map an object like this to some relational tables. And even if you manage to do it, the business objects contains ORM specific artifacts such as virtual properties, attributes or properties acting as foreign keys, all things that have no place in the business object. After all, the ORM entities represent the database, they are objects who store state optimized for querying, so WHY are you using the database directly in the Business Layer!? And why a business object should EVER care about lazy loading?! Is lazy loading a business concept?

Oh and you will have to fight one big problem too: the unmaintainability of the code will raise exponentially with the rich behavior. You'll have a technical nightmare which can be avoided if you understand the ORM's place. Btw, CQRS helps a LOT when dealing with rich behavior.

Every time you're using the ORM's entities as the base for the Domain entities, you're violating the Separation of Concerns(SoC) principle. You're simply mixing together the business logic and the persistence logic. Even worse with DDD is that you start from the ORM which models a relational schema after all and then try to fit business behavior on that structure. Business objects are not the same and they have not the same purpose as the database objects! One models behavior while other models how state is persisted and queried. Different concerns! When you are modifying business objects to care about the ORM, you are leaking persistence technical details into the Domain, hence the SoC violation.

When modeling business objects, please FORGET that you're using an ORM. Use the Repository pattern to bridge the Business Layer to the Persistence Layer. The ORM is a persistence layer detail, so use it just for its intended purpose: as an object oriented database where state is stored in objects (entities) optimized for relational querying. If you don't care about relations just use a Document database or save the business object in serialized form.

I know that in theory the ORM should map ANY object to relational tables, but let's be honest: that ORM Entity accurately represents one or more relational tables in the db. Their properties are mostly primitives which are easily mapped to RDBMS suported types. Any ORM entity is designed with the relational database mindset.

For example, I'm curious how the tables and mappings for this object would look like

public class MyObject
{
 /*some concrete types may have constructor dependencies */

  public ISomeInterface Property1 {get;set;}
  public List<IOtherInterface> Property2 {get;set;}
  public MyValueObject Value {get;set;}
}

In conclusion, ORMs are GREAT for simple, CRUD applications. You don't want to use one if querying performance is very important and you have to be careful with it when dealing with behavior rich applications. Don't forget that the ORM follows a relational database mindset, while the Business Logic follows the actual Business mindset.

7 Biggest Pitfalls When Doing Domain Driven Design

By Mike on 13 May 2013

Relational database mindset masked as DDD

This is so easily recognizable: it starts with data structures, finds one to many, many to many relations, loves the ORM and it knows that lazy loading is a necessary evil. Probably all devs doing this believe that DDD stands for Database Driven Design.

Domain Driven Design it's not about the data or the relations between data. It's about modeling the relevant business concepts and processes. When modeling account and clients for a Bank, you would never hear the domain expert saying: "We have a many to many relations between accounts and clients". You might hear something like: "A client can open multiple accounts.Two clients can share the same account".

Database mindset automatically 'knows' that a Client has many(a list of) Accounts. But the Domain mindset understands that a Client doesn't have an Account. The Bank opens up an account and gives the Client access to it. The Client never has an Account, he's merely an user of Account.

Modeling Domain is a different task than modeling Persistence. Both are important but are different things and require a specific mindset. When modeling asks yourself what are you modeling: business processes or relational database schema.

Treating DDD as a recipe

DDD it isn't a way, a method of how to do things. It's a mindset to design an application. And it's a very simple mindset: the application Design is Driven by the business Domain. There are no steps of how to do DDD and there isn't a formula you can learn. What you can learn from Eric Evans or other DDD experts is how they approached a problem, but nobody can give you a sure recipe of how to do things.

And one big mistake is to think that if guru X did it this way, clearly you should do the same. Every application is unique, what worked in one case might be a wrong and complicated approach for other case.

Starting with technical details

Begin modeling from a technical point of view (what are my aggregate roots, is Customer an entity, should I use an ORM, I have this Aggregate Root so I must have a Repository also etc) instead of the Domain's  i.e too much technical mumbo jumbo and too little 'philosophy'. Bounded contexts, aggregates, entities etc appear naturally when you understand the Domain. The point is: let the Domain guide the code and not viceversa. You don't try to fit the Domain into the programming language or a framework. You are just expressing the Domain using code.

I've seen a lot of debates if a method should belong to an Entity or to a Service. Is it a Domain Service, is it some other Service etc. These are just technical words which just complicate things. Just follow the Domain (the business) and see what it makes more sense from a business point of view, what it naturally fits. I repeat myself: there is no recipe and the technical aspect is secondary to the business aspect.

Being superficial about the Domain

It's easy to mistake the method for the purpose. In real life you put files into a folder. Why do you do it? Is it because you just want a place to put the files and it just happened to be a folder lying around or is it because you want to group the files according to a topic and the folder is the most obvious choice? What is the folder's main purpose: storage or grouping?

Treating the Aggregate Root (AR) as a container

This is a very common side effect of the previous pitfall, it's very easy to consider that all an AR does is to 'hold' the Aggregate's other objects, especially Value Objects. This is tricky stuff actually, and the only way to not fall into the trap is to properly understand the domain.

As an example, let's take the famous Order. Most of the time you'll find the Order as a collection of OrderLines which can be added or removed plus some methods to calculate totals, taxes etc. However.... an Order is not the Cart where you add/remove products until you submit the order. The Order is the list of products and quantities the customer ordered from you. That's it and nothing more and this means the Order is immutable. It doesn't even has methods to calculate totals because the client didn't order totals or taxes. All the order's financial data is in an Invoice. This means you don't add discounts to an Order either, again because the customer didn't order discounts.

The Cart is a container of products and quantities until submitted when it becomes an Order which has an Invoice attached. The Order seems to 'hold' OrderLines but in fact, an Order can't exist without at least 1 OrderLine. A Cart can exists with 0 items in it, it's called an empty cart. Also, the importance of the Order is not that it's (in the end) just a list of OrderLines but a business document. The order lines are just an implementation detail.

As a thumb rule, if all the AR does is to have a list of something, without representing a specific business concept, it's a strong hint you didn't model an AR but a simple container.

Tying the Domain to the ORM, an artifact of the database centric mindset

When using an ORM, the ORM becomes the relational database but without Sql and presented in an object oriented view. Mixing the ORM with the Domain it's like writing Sql from your business layer: a violation of the Separation of Concerns (SoC) principle. The ORM is not here for the Domain, it's here to protect developers from the ugly Sql.

The "One model to rule them all" approach

  • Bounded Context (BC).
    A business concept may have slightly different definition depending on the context. In the Finance BC, a Product might mean only an id and a cost while in the Marketing BC, a product is an id, name and other relevant marketing details. The Inventory BC has all the technical details of the Product. The point is each BC understands something else when using the same concept. And the Inventory definition resemble but it's not the same as the Marketing definition. Even if they share the same name 'Product' they are different models, relevant only in their specific BC.
  • Technical constraints.
    Even if you have only one definition of the Product, if the object is not anemic i.e it is an aggregate root with behavior it will be a technical challenge to update and query the model. You can store it optimized for querying but it will be complicated to save/restore it from the db. You can serialize the object (trivial save/restore) but it's a pain (very slow) to query. In this case you need to have 2 models: one rich for updating and one 'dumb' for querying (CQRS). There's no need to complicate your life, good code is simple, clean code.

You know  you're applying DDD right when the Model is clear and flows naturally. Yes, it's a bit Zen like. And you can be pretty sure that you're doing it wrong when everything is so complicated that you cringe inside every time you have to change something. Remember this thumb rule: if it hurts then you're doing it wrong.

CQRS Explained

By Mike on 4 May 2013

I find it refreshing that CQRS is more and more used. What surprises me is the for many developers this is considered a 'big leap', something involving learning 'advanced' stuff and complex frameworks. But CQRS is just a very simple and straightforward concept: Command Query Responsibility Segregation (Separation).

Let's take it step by step.

A Command is behavior which modifies the Model. A Query is well... querying (reads) the Model. Why the separation? Think a bit: modifying the Model usually means business rules validation and interactions between business objects. It's a 'rich' Model. When we want to query the same model, we have to restore it from persistence (which can be very slow), populate all the objects, instantiating business rules etc. All this just to get the Name for some Product. How about the names for 1500 Products?

Sure we can store things directly in a queryable form, that's why you're using a RDBMS, but restoring the state especially when dealing with complex relations between the objects it's a complicated affair.

But someone smart pondered the things and wondered: querying the model doesn't change it, so instead of complicating my life, how about I use models optimized for my tasks? If I want to change the model, I'll have a rich and relevant business model but when I want to query it, I'll have a simplified, optimized for reads model. So, instead of having only one Model trying to please two different scenarios, I'll have one model optimized for each scenario.

But wait, doesn't that mean we have to write more code and breaking the DRY (Don't Repeat Yourself) principle? Not quite. First of all the query model, usually referred to as the read model is just a slimmed down version of the richer model. Of course, depending on the contexts you could have more than 1 read model.

The DRY principle isn't violated, because our read model is just 'dumb' data. The advantage is that each context gets its own relevant and most importantly easy to use model which simplifies the understanding and the maintenance of the code.

And this is all that CQRS means: have a different model for changing state (command) and for reading state (query). That's it, nothing more and nothing less

I'm sure that searching about CQRS you came across CQRS frameworks and Event Sourcing, but I'm afraid that CQRS only means the simple thing stated above. You don't need a framework for such concept, it's impossible to have a framework. What frameworks/toolkits you've found are in fact for Domain Driven Design or Event Sourcing (ES) or Domain Events etc which happen to use CQRS.

CQRS is a great concept to be used in any application when one model means complicated code and that's why is a perfect fit with DDD, ES or a Message Driven Architecture. You'll find them used together, but each means something else and a good developer should understand what each pattern brings to the table. They are tools not buzzwords.

DDD: Persisting Aggregate Roots In A Unit Of Work

By Mike on 1 May 2013

There comes that time in DDD when you have to include two or more Aggregate Roots (AR) in a transaction (unit of work). They can be modified that's no problem, but how to persist them?! We have one repository per each AR and each AR actually defines the boundaries of its own transaction. How can we save all the Aggregate Roots in a Unit of Work?

There are 2 cases:
1. You are using one transactional storage like a RDBMS. In this case things are very simple: wrap the db transaction in a UnitOfWork and see that all involved repositories receive the db transaction via their constructor. This becomes even simpler if you're using an ORM.
2. You are not using a transaction storage or there are multiple data stores involved. Even with a RDBMS, once there are 2 databases involved you can forget about transactions. What to do then?

The good news is that you're using DDD so let's think a bit. What is the main advantage of DDD? You are modelling in code the business concepts and the business processes. This means that the business workflow can tell us how to achieve that transaction.

Let's consider this example: we have an Inventory and an Order. These are our AR and we want to simply move the goods from the inventory to the order, which in code is just something like subtract quantity from Inventory and add the same quantity to Order. A typical transaction.

But let's see how it would be done in the real world. Let's say that we have 2 rooms: Inventory and Order. First of all, you don't just add/take goods from an Inventory without a business reason. Stock is increased when the suppliers delivers the goods and decreases when the goods are moved to the Order (or other business activity). Same with Order, goods don't just appear from thin air. Usually they come from the Inventory. This aspects are important in understanding how we should model the transaction.

So, we want to move 3 goods from Inventory to Order. This means that you take the 3 items and transport them to the Order room. In this period of time, the Inventory will have (stock-3) items, while the Order is unchanged. But this is not a problem, it's something normal, you can't just teleport things around and even if you could, there will still be some slight delay. Until the items are put in the Order room, we can say that there is some inconsistency with our inventory but that doesn't bother anyone because things will become consistent quickly.

The goods arrive in the Order room so the transaction is successful. But what if there is a problem? If the Inventory doesn't have enough goods, then nothing will be sent to the Order and the transaction is refused on the spot. But what if the Order refuses the goods (because it already has them)? In that case, the natural way is to return the goods to the inventory. Once returned, the Inventory will have the same stock as before while the Order doesn't change anyway. It's a real life rollback.

Knowing these things, it becomes trivial to implement them in code. But here is a tiny catch: it requires a message driven approach and being very comfortable with the concept of eventual consistency.

So, we have Inventory and Order aggregate roots used in a unit of work. Instead of doing: begin transaction -> modify inventory -> modify order -> save inventory -> save order -> commit , now we'll use the workflow as it happens in the real business.

You don't say to Inventory: 'substract 3 from stock" you say: "Inventory AllocateQuantityForOrder". If it can do it, the Inventory modifies its state then generates an event: GoodsAllocatedForOrder. One of the handlers of that event will update the Order: ReceiveGoodsFromInventory. If all it's ok, the Order change its state. If not, the event handler will issue a ReturnGoodsToInventory command, which is basically a rollback for the Inventory.

And here you have it, a transaction involving 2 aggregate roots that doesn't depend on a transactional storage. Let's see the differences between these 2 solutions.

First option is the conventional one, the simplest to understand and to use but:
- it requires at max one transactional storage.
- it requires that the modifications be made in the same time, you can't span the transaction over 2 web requests for example.
- you can't use more than one storage.
- poor scalability.
- it doesn't leverage DDD.

Second option is clearly a bit more exotic (if you're not used to message driven apps) but:
- it takes advantage of DDD thus it's modeled by the business process, so it's a natural fit.
- works in a distributed environment.
- it's storage agnostic.
- it can be scaled easily.
- it requires good developers and a proper understanding of the Domain and being comfortable with message driven architecture.

I favor the second approach, but the first option can be the pragmatical solution for some cases. It's important to take your time to think and choose what option fits your app better. Remember that the devil hides in the details so don't be hasty about your decision.

Message Driven Architecture Explained: Eventual Consistency and Saga

By Mike on 30 April 2013

You can find part one here

Let's talk about the really interesting stuff about Message Driven Architecture (MDA).

Eventual Consistency

Most of the time you might use a RDBMS which enforces consistency and you know that if the transaction has been committed, everything is saved. When dealing with distributed components availble on different servers, suddenly you can't use this feature. The same problem appears in a local application when you're using NoSql db or you have to save data in 2 databases belonging to a RDBMS or you have 2 or more incompatible data storage (for example: file system and rdbms).

With MDA you need get used to eventual consistency which can be explained very simply: everything will be consistent.. eventually. The thing is, a model is consistent at one moment in time. For example, a web page shows some data. The data is a valid model until you refresh the page. If you don't refresh it then for you the model doesn't change, even if on server it's already different. However, eventually, you will refresh the page and you'll get the latest model which of course might change 1ms after the page loaded.

Eventual consistency is everywhere around us, we all work with obsolete data, but the RDBMS have spoiled us to think that we can have always access to the latest, accurate and 'true' data. This works when using only one RDBMS but that's it. Change that condition and we're back to the real world where everything gets stale after a second. Embracing (the natural) eventuality is required for MDA and it's not that hard to get used to it, actually.

So, how do we deal with it? Well, quite simple actually. Since in MDA every business object is modified as the result of a command, it means that the commands themselves need to be committed together as a unit of work. Every ServiceBus has the feature to send more messages at once. This is the 'transaction'. Note that the important part is that the commands will be received together, but that doesn't mean they will be handled at the same time. But this doesn't matter as they will be all handled eventually :)

Saga

A Saga is used to manage a long running process. Got it? No? Well, there are some long running operations which are considered to be complete when all their steps are completed. Nothing unusual except the fact that each step can be completed independently of other so there isn't a predefined order. Another aspect is that steps are completed in unknown time periods, so one can take 2ms while others minutes, hours or days. The saga keeps track of these steps as they happen and ends when all involved steps are completed.

Let's consider this real-life example: John goes to a fast food restaurant and orders a menu. This means one hamburger, one portion of fries and one soda. John tries to pays with the credit card... if he finds it. For whatever reason, it's not in the usual place. In the mean time, the employee get the soda and tells John he has to wait a bit for the hamburgers and the fries. John finally finds the credit card and pays. After a few minutes everything is ready and he can enjoy his meal.

Now, in this example we don't care much about John (sorry!) but we care about the operation as seen from the restaurant point of view. The operation is complete when the whole menu is ready and paid for by the customer. We have the following steps:
- Hamburger ready;
- Fries ready;
- Soda ready;
- Payment received.

The important thing here is that any of these can be completed in any order. Remember in our example that the order was:
- Soda ready
- Payment received
- Hamburger ready
- Fries ready

Usually things probably happen in a slightly different order depending on how you pay and if the menu items are already prepared.

Now, let's 'write' the above example as a saga.

John orders a menu, that is the OrderSubmitted event is published which starts the operation (saga). Starting the saga means issuing the commands: PrepareHamburger, PrepareFries, PrepareSoda, ReceivePayment. It just happens that E will handle all the commands: first E checks for each menu item to see if they are available. Hamburgers and Fries are not so two other commands MakeHamburger and MakeFries are sent. The Soda is available, so the SodaReady event can be published which signals the saga that one step has been completed.

In the mean time John pays so the PaymentReceived event is published and saga marks another step as completed. After a few minutes the HamburgerReady and FriesReady events arrive and the saga marks the last items' completition. All the steps are completed so saga ends, preferably with the SentOrderToClient command.

Here we have 2 actors: the employee (which is the messages handler) and the saga. A saga is started by an event and it's updated by other events. All these need to be correlated so there is usually a message property which acts as the correlation id (for example OrderId). All that saga does is to coordinate events and commands. In the above example, saga began by sending a few commands then handled the events which updated its progress and when it completed, it sent a final command.

In this example 'long running'  meant a few minutes. But consider the case where you order something online, you pay now but the seller may get the payment confirmation after 5 minutes, the items will be available in 3 days and you'll get the products delivered after 1 more day. The PrepareForDeliverySaga starts with OrderSubmitted and ends when both PaymentReceived and ProductsInStock events are published. The saga may end with a ShipProducts command which will generate a OrderShipped event which in turn may start a ShippingSaga which ends when the customer has received and signed for the goods. Or you can include the OrderShipped and OrderDelivered steps in the first saga.

And this should be all, I hope now you have a better understanding of what Eventual Consistency and Saga are.

Message Driven Architecture Explained: Basics

By Mike on 19 April 2013

You might know about Message Driven Architecture (MDA) if you've heard about the Domain Events Pattern or Event Sourcing. As its core, MDA means that an application is composed from autonomous components which communicate with each other via messages. MDA is very common in a distributed application, because each component sits on a different server but they still need to work together.

But the amazing thing about MDA is that it can be applied for local (non distributed) applications as well. This means that a local MDA application can easily become a distributed app, only some configuration is required, but the app code should remained untouched. The main benefit though is that it makes it very easy to write high quality, maintainable code i.e lowly coupled, highly cohesive and highly testable code.

The downside is that it requires a bit of experience to become comfortable with it. It's not straightforward and at first, it seems like over engineering, but once you experiment with it, it will feel like the proper way to implement a non trivial application. But for that, you need to understand MDA properly.

How It Works

Let's say you have 3 modules: Sales, Accounting, Inventory. These 3 obviously need to work together but we want these modules not to be coupled one to another. Each module knows that the other exist, but they don't know where and how to talk with them. They are pretty decoupled.

In order to work together, these modules will pass messages to each other via a 3rd party, a 'transporter' which knows where everyone is. That transporter is called a ServiceBus and that's its sole responsibility: to deliver messages to a destination.

In a nuthsell things goes like this:

  • Module sends a message to the ServiceBus.
  • ServicesBus delivers the message to one or many configured destinations.
  • Destination receives and handle the message.

Note that the sender and the receiver modules don't know about each other, they know only about the ServiceBus. This means that modules can be added or removed without other modules being affected.

Messages

A message is a simple data transfer object (DTO) which contains message name and details. A message should be as simple as possible and serialization friendly.

A message can be a:

  • Command - the message tells that its handler must do something. The message name is the Command while its content are the command arguments. Good names are imperative ones: CreateOrder, RegisterPayment etc. A command is sent via the ServiceBus and can have only one handler.
  • Event - the message tells that something have happened. A good event name represents an action in the past: OrderCreated, PaymentSubmitted etc. An event is published via the ServiceBus and can have 0 or more subscribers.

A message handler is the object which processes the message. There are Command Handlers (or Executors) and Event Subscribers. A message handler can send messages as well.

Idempotency

One important detail about MDA is that a message is guaranteed to be sent at least once. This means that a handler can receive the same message twice. The reasons why that happen are mainly technical in nature and a handler must be able to cope with this behavior. That is no matter how many times a message is processed, the outcome must be the same. This is called idempotency.

Some actions are naturally idempotent, for example a=3. Invoking a handler that assigns 3 to a variable will have the same result no matter how many times is done. But if, let's say, the variable is incremented then each invoke will get a different result. For these cases, the message handler must take additional steps to ensure its idempotency.

Ensuring idempotency is an app specific action, but usually is done by having in the database a unique key for the processed message. For example, inserting a new Product will also insert the message id. If the operation is a duplicate the db will refuse it. In this case the datastore is the actual enforcer of idempotency. This example also shows that idempotency is a concept that goes beyond the message handler.

These are the basics of message driven architecture. In the next post I'll talk about the cool stuff.

How To Create Your Own Asp.Net Mvc View Engine From Scratch

By Mike on 18 April 2013

There are a number of reasons you might want to create your own view engine for Asp.Net Mvc. Mine was that I wanted to have finer control over configuration. You can do a lot with the default view engine but you have to use the golden hammer of inheritance. And for some 'advanced' features like theming you need to modify it (how lucky that asp.net mvc is open source).

Anyway, regardless the reasons why you want to create your own view engine, here's how to build one from scratch. Warning: Code heavy post.

In Asp.Net MVc the view engine has 2 concerns: to locate a view and to instantiate a view. Note that it has nothing to do with the template parsing and rendering so the same view engine can be used to render Razor, Webforms, Spark etc. It's important to understand the difference between the view engine and the template engine.

Here, I want to create a flexible view engine, that is, it can be easily configured via conventions and can support any template engine.

public class FlexibleViewEngine:IViewEngine
{
    public ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName, bool useCache)
    {    
    }
    
     public ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
    {
    }
    
    public void ReleaseView(ControllerContext controllerContext, IView view)
    {
    }
}

These are the methods required by IViewEngine. You can see the ViewEngineResult which will be returned in both success and failure scenario. The difference is the when failed, it will contain a collection of searched view path, the ones you see in the yellow screen of death when asp.net mvc can't find a view.

I've said above that this view engine will know how to work with any template engine and this means that it will require view factories injected in it. For easy config, I've decided to have a FlexibleViewEngineSettings object where factories can be added.

public class FlexibleViewEngineSettings
    {
       
        public List<IViewFactory> ViewFactories { get; private set; }

      
        public List<IFindViewConvention> Conventions { get; private set; }
        
    }

 The Conventions list holds the conventions used to locate views.

The view engine accepts an action that can be used to add view factories and view locator conventions.

private FlexibleViewEngineSettings _settings=new FlexibleViewEngineSettings();

    //constructor
    public FlexibleViewEngine(Action<FlexibleViewEngineSettings> config=null)
    {
        if (config != null)
        {
            config(_settings);
        }
        
    }

How does a convention looks like?

public interface IFindViewConvention
    {
        bool Match(ControllerContext context, string viewName);
        string GetViewPath(ControllerContext controllerContext, string viewName);
        string GetMasterPath(ControllerContext controllerContext, string masterName);
    }

Each concrete convention must decide when to apply and how to create a path for a given view or layout. One example can be the case of an Ajax heavy site that still wants to be indexed by search engines. When a search crawler is detected, a special SEO tailored view can be used.

A view factory interface looks like this

public interface IViewFactory
    {
        bool IsSuitableFor(string fileExtension);
        IView Create(ViewCreationData settings);
        IView CreatePartial(ViewCreationData settings);
    }

The concrete factory will be used only for view paths ending with a suitable extension. This means that conventions (the view path generator) and factories work together. Although a partial view is a view, it's necessary to have separate methods because a partial view has special needs, for example, in razor case it should ignore _ViewStartPage .

Ok, so now we have conventions and view factories in our settings. Let's see how they are used by the view engine.

The main idea is that for a given view it processes all the conventions and uses the first which returns a valid view path. It then uses that path to search for a view factory which can handle the file extension. After that it asks the factory to create a IView instance which is returned via the ViewEngineResult object.

 If a returned view path isn't valid, it's added to a list of searched paths. If no conventions returned a valid path or there are no view factories which can handle it, an 'error' ViewEngineResult is returned containing the list of searched paths. That's all, pretty easy.

And once the view engine is built along with some conventions and view factories, just hook it up

ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new FlexibleViewEngine(v =>
        {
            v.Conventions.Add(new MyViewConvention());
            //another view factory
            v.ViewFactories.Add(new MyViewTemplateFactory());
        }));

I've included a Razor view factory and the Asp.Net Mvc view conventions (cshtml only and with theme support) by default, so this configuration is for only when you want to use your own conventions or another template engine.

Here's an example of how to write a view factory

public class RazorViewFactory:IViewFactory
    {
        private string[] _extensions = new []{"cshtml","vbhtml"};
        public bool IsSuitableFor(string fileExtension)
        {
            return _extensions.Contains(fileExtension);
        }

        public IView Create(ViewCreationData settings)
        {
            return new RazorView(settings.Context, settings.ViewPath,settings.MasterPath, true,_extensions);
        }

        public IView CreatePartial(ViewCreationData settings)
        {
            return new RazorView(settings.Context, settings.ViewPath, null, false, _extensions);
        }
    }

That's all! You can check the entire FlexbileViewEngine code here

Benefits Of Using A DI Container

By Mike on 10 April 2013

The good news about writing a trivial app is that you don't need many things. Only some basic coding skills and a 'get it done' attitude. Design patterns, SOLID code etc are not required. It's code and forget. Easy and practical.

However, when dealing even with moderately complex apps things are different: there is advanced functionality required and changes are the norm. Suddenly, the way the app is designed and how the code is written matters. At that point, we care a lot about maintainability, which implies decoupled code. And decoupled code means that most objects will take one or more abstract dependencies.

So we have objects which require dependencies. That's not a problem as it's easy to provide those dependencies manually. Unless those dependencies themselves require dependencies and so on. At that point, a manual solution becomes cumbersome. A better, automated solution is needed and here is where the DI Container comes into play.

There is a saying among developers: "When learning about DI Container you don't understand why you really need it, but after you start using it properly, you wonder how you managed without one".

The most obvious benefit of a DI Container is the automated wiring of all dependencies. 1 or 100 it doesn't matter, the Container knows how to provide them. It's almost magical. But the benefits don't stop here.

Fact is, a Container is a factory which creates objects on demand. But it doesn't just creates them, it can also manage their lifetime which is an important feature. You might be aware that the Singleton pattern can be viewed as an anti pattern, mainly because of the static property which messes up testing and multi-threading scenarios. Oh, and breaking the Single Responsibility Principle, because the object gets the additional task to handle its own lifetime.

Using a Container, you just tell it to treat an object as a singleton so the same instance will be used every time. The object itself doesn't know that it'll be used as a singleton so there's no need for private constructors or static properties. The object is relieved of the task to manage its own lifetime. You get less code and increased testability.

But that's not all, as you can set the Container to return the same instance for a defined scope, for example a request in a web app. Any time the object is needed in that scope, you know there will be the same instance. And speaking of scope, most Containers knows how to handle IDisposable, so when the scope ends any disposable object will be disposed as well.

Containers are also useful when you have interfaces (abstractions) defined and you need instances of concrete but unkown types. This is the a very common usage in business applications which, for example, define abstractions for business rules then need the actual implementations. With a Container you just register all types implementing the interface (every Container has a method to scan and register types matching a criteria). Then the business rules engine asks the Container for instances of types implementing a certain interface (or just takes a dependency on a List<IBusinessRule>) and uses them. The benefit is that you can add lots of business rules implementations (new types) and they will be automatically used without needing to change or to add any other code. And the important detail is that at least some of the concrete objects have one or more dependencies.

When you have a complex app, you have lots of code, especially lots of objects. A Container makes it easier to achieve low coupling and lets you focus on proper object design as you don't have to deal with object instantiation or dependency lifetime. Of course, you will instantiate manually a lot of objects, but none of them will be a dependency.

Now, the most common antipattern when using a Container is something like this

public class MyClass
{
   public MyClass()
   {
      var dep1=Container.Resolve<Dependency>();
   }
}

This code invalidates the use of a Container because:

  1.  MyClass is tightly coupled to the container
  2. None of its dependencies are actualy injected

The proper code should look like this

public class MyClass
{
   public MyClass(IDependency dep)
   {
     //assign dep to field
   }
}

MyClass doesn't know that a Container is used, it knows only about an abstract dependency. It's the usually the job of a framework to call the Container for an instance of MyClass. In your code you should try to refer to the Container as little as possible so that very little code should actually depend on the Container itself.

Good code knows only about its immediate dependencies and those should be abstractions. When an object requires an outside object which is not injected as a dependency, you have a tight coupling problem. So use only the injected dependencies and let the Container do the wiring.

P.S: Some Containers feature Interceptions which are used to implement Aspect Oriented Programming (AOP). In my opinion, this is an optional feature that isn't directly related to the main job a DI Container does. An AOP dedicated framework is a better choice.

Asp.Net Mvc Apply Filters By Convention

By Mike on 9 April 2013

After using conventions to define routes, how about using conventions to apply filters? I mean, I have to decorate every controller in the Admin section with at least 2 attributes: [RequirePermission(UserRights.Login)] and [OverrideTheme("admin")]. I'm using the Handler convention so basically I have as many controllers as I have actions. I also want to enable [SmartAction] for all POSTs and to have some specialized Ajax Only Controllers.

The default way is to clutter each action (or controller) with a stack of attributes or worse, to have a base Controller with these attributes and the inherit from it. I consider the inheritance solution to be a poor one, this is one of the cases where you shouldn't use it.

We need a better way and luckily, it's trivial to implement one. The idea is very simple: I want to apply a filter according to a convention. Of course, I start with an interface to define a filter policy. All the filters are considered to be global filters.

public interface IFilterPolicy
    {
        int? Order { get; }
        /// <summary>
        /// Filter instance
        /// </summary>
        object Instance { get; }
        
        bool Match(MethodInfo action);
    }

This policy is then used by a filter provider to know when to return the filter. As I've said, it's trivial.

internal class FiltersWithPoliciesProvider:IFilterProvider
    {
        Dictionary<string,IEnumerable<Filter>> _filters=new Dictionary<string, IEnumerable<Filter>>();
        public FiltersWithPoliciesProvider(IEnumerable<FilterActionInfo> filters)
        {
            foreach (var filter in filters)
            {
                _filters.Add(filter.Key,filter.Filters);
            }
        }
        
        
               public IEnumerable<Filter> GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor)
        {
            var key = FilterActionInfo.CreateKey(actionDescriptor.ControllerDescriptor.ControllerType,
                                                 actionDescriptor.ActionName);
            IEnumerable<Filter> filters;
            if (!_filters.TryGetValue(key, out filters))
            {
                filters=new Filter[0];
            }
            return filters;
        }
    }

For a quick and elegant setup

//setup DI container
    builder.RegisterAssemblyTypes(ThisAssembly).Where(t => t.DerivesFrom<IFilterPolicy>()).AsSelf();

   //tell FiltersPolicy where to find actions and policies
     FiltersPolicy.Config.RegisterControllers(asm);
     FiltersPolicy.Config.RegisterPolicies(asm);
     
     //tell FilterPolicy to build and register the provider
     FiltersPolicy.Config.RegisterProvider(FilterProviders.Providers);

Now let's write some conventions

//All admin views are using the Admin theme
 public class AdminThemeIsFixed:IFilterPolicy
    {
        public AdminThemeIsFixed()
        {
            Instance = new OverrideThemeAttribute("admin");
        }
        public bool Match(MethodInfo action)
        {
            return action.DeclaringType.Namespace.Contains("Admin");
        }

        public int? Order { get; private set; }

        /// <summary>
        /// Filter instance
        /// </summary>
        public object Instance { get; private set; }
    }
 
 //All controllers from Admin must be authorized
  public class AllAdminActionsRequiresLogin:IFilterPolicy
    {
        public AllAdminActionsRequiresLogin()
        {
            Instance = new RequiresPermissionAttribute(UserRight.Login);
        }
        public bool Match(MethodInfo action)
        {
            return action.DeclaringType.Namespace.Contains("Admin");
        }

        public int? Order { get; private set; }

        /// <summary>
        /// Filter instance
        /// </summary>
        public object Instance { get; private set; }
    }
    
    //All actions from controllers having ajax in name are constraint to ajax requests
  public class AjaxControllersConvention:IFilterPolicy
    {
        public AjaxControllersConvention()
        {
            Instance = new AjaxAttribute();
        }
        public bool Match(MethodInfo action)
        {
            return action.DeclaringType.Name.Contains("Ajax");
        }

        public int? Order { get; private set; }

        /// <summary>
        /// Filter instance
        /// </summary>
        public object Instance { get; private set; }
    }

There you have it, the easiest way to apply filters selectively via conventions. Now, your controllers are less cluttered and you don't have to remember all the attributes or to misuse inheritance.
 
 Note that this doesn't interfere with the global asp.net mvc filters, so you can register some filters to apply to every action while other are applied according to a convention. You can check out the whole source here.