Entity Framework and some Architectural Decisions

I recently read an article on getting around how Entity Framework works in regards to trying to simulate it into the MVC Storefront app that Phil Haack did a video series on recently. Muhammad Mosa does an excellent job writing on the same experiences I faced when trying to mock up a architecturally sound design utilizing Entity Framework (swapping out Linq to Sql).

In this article, Muhammad mentions 2 ways to get around the short comings of what it can project client side vs server side and how to map that into a Repository that flows with fluent filters as extension methods like the MVC Storefront application series.

The first way he mentions is the Virtual Proxy pattern class that wraps the entity object, and allows you to lazy load its references and the object itself when you reference its properties.

The second way is to explicitly define a complex projection (the select new from a Linq statement into another typed object - such as a data transfer object (DTO)) as a client side query with the AsEnumerable method, to pull all of the data from the database into memory to do some complex shaping, but leave its child references as IQueryable to lazy load.

Please refer to the above link to read Muhammad's article to get a clearer picture of what this means.

I decided to discuss these approaches in the comments, and realized how long the comment got, so I wanted to post it here for any readers to join in the discussion, so that hopefully, we can come up with a cleaner solution.

Entity Framework Architectural Discussion

The bad thing about the second way (i.e. the Client side evaluation), besides the mass amounts of data you need to pull into memory, is that now you are segregating your methods into some, like GetCategory7() with a AsEnumerable() and the GetProducts() with no AsEnumberable(). So you are segregating how you handle each pull from the Data Store based on what is the Main object, and its child references, which isnt all that bad if you have a repository per main object call.

However, supposebly you would have a Product Repository which has to duplicate what you are pulling from your Category Repository but with an AsEnumerable to correctly shape it.

This will make for duplicate logic in pulling data depending on if you need that entity as a child reference or base object.

Based on that alone, I would stick with the first option, which is basically a Virtual Proxy Pattern on top of each entity object. The problem here is the mass amount of mock up for each Property, especially when you already went through the trouble of creating your Model in the EDM. Now you have do it through the Entity Framework Model, and your wrapper proxy class, every time something changes. Again, excessive duplicate work.

Unfortunately, I hate to say it, but the third way it seems is just using Entity Framework as the Repository object that calls into each entity is probably the less work way, but couples you completely to EF. You can then marry your Business rules and logic to the partial of each entity. This also allows you to utilize ADO.NET Data Services in a seamless way to expose your domain layer to multiple applications (which you can do with the first and second way but you will need to implement IUpdateable in your Repository -> which can be a pain).

There is no "utimate" way to do this at this time. But to me, saving work up front, especially when it could change for v2 is probably a simpler way. But layered wise, the proxy pattern approach is definately more architecturally sound, the problem is you are back to building out your DTO objects that match your entity model, basically regurgitating out each new property in your proxy DTO class.

I dont know, but for situations where I want to utilize ADO.NET Dataservices, approach 3 seems the better route now, I just hope when POCO objects make there way, I dont get burnt in having to re-write much.

Essentially, the typical data layer model has you making a Repository Layer, a Service Layer (your business layer), and the application Layer (your MVP/MVC layer).

By utilizing EF at the Repository Layer, you completely couple yourself at that layer to EF, but gain the flexibility to easily change your model independently from your data schema (which is typically what the Repository does anyway).

I am testing out using the ADO.NET DataService as the service layer, since you can inject before query calls, and on updates/creates/etc. Unfortunately, to fully utilize my rules logic, it is simpler to push that into the partial for each entity, and throw an exception which I can trap in the DataService layer and respond out.

From there my Applications Model Layer in a MVC application will handle making a Application Business Layer that is specific for that application that simply consumes the ADO.NET Data Service to get the data and utilize the entity in the application. So rather than trying to make my Domain Layer with EF/ADO.NET Data Services be the business rules for everything, it just handles making sure my domain rules are correct for my model, and the application itself handles business rules that are correct for that specific application (since this model is for multiple applications to consume this -- it cant be everything to everyone, but it can make sure it is valid at a domain layer).

Hope this helps, this is just some of the things I have played around with. Maybe we can poke holes in both our ideas enough to come up with a cleaner solution.

Extension methods as a new Fluent Decorator Pattern?

So recently I have been on this kick to learn Design Patterns in Ruby, and to figure out all kinds of neat ways to do the same design patterns in a dynamic language that is as versatile and elegant as Ruby. While playing around with the decorator pattern in Ruby, I started trying to think of slick ways to accomplish the pattern in C# 3.0.

In Ruby, there is a really slick (and somewhat dangerous) way to handle the means to accomplish the decorator pattern in Ruby (hold on guys, I am getting to the C# part in a bit, I am trying to explain how I got there):

Imagine a string class that holds a string with a method called “write_line”. Suppose for some reason you wanted to apply a decorator pattern to this, and decorate the string at runtime to make the string perform in various output ways. In Ruby, you could tackle it the GoF (Gang of Four) ways, or you could do the following:

Alias method Wrapper:

Decorate with Modules:


Ok, so since Ruby is so dynamic, it can on the fly edit the class instance and inject objects in the inheritance chain after the class itself. So you can utilize this to decorate your base functionality at runtime.

However, C#, since it is statically typed, really won’t allow you to tackle it this way. I started thinking about some of the new features in C# 3.0, and some of the things I have read about, and some of the things I have played around with using Piping, Filtering, and a Fluent Interface (I first started learning about this on the MVC Storefront series by Rob Connery [I highly recommend watching this series btw]). It occurred to me, that although we can’t accomplish the decorator pattern the Ruby way, we can accomplish it a nice readable way using Piping and a Fluent Interface way.

Take for example the standard Decorator Pattern typically seen in C# (using the above example in the classic GoF way):

var outputString = new List<string>{“hello”, “world”, “this”, “is a”, “test”};
var myDecoratedString = new NumberingString(new TimeStampString(new SimpleString()));

myDecoratedString.Write(outputString);


The above would use the chain of sequences called by Write to build out the string that is Timestamped, Numbered, and outputted.

This is fine and dandy, but not very pretty to look at in the least. And since the Decorator Pattern, is basically hiding the base object (that does the real work) in itself, it is simply chaining it out till it gets to the base object (“chaining” being the operative word here – similar to Piping).

So what if we do this in a fluent type of way?

var outputString = new List<string>{“hello”, “world”, “this”, “is a”, “test”};
var myDecoratedString = new SimpleString().WithNumbering().WithTimeStamp();
myDecoratedString.Write (outputString);

This is much more readable if you ask me, and it is very clear and concise into what is happening. It is saying that you want a SimpleString object that has Timestamp and Numbering to decorate it.

The Decorator objects have been transformed into extension methods that act on the SimpleString object and decorate it from the extension method.

A simple example of this would be the following:

Output would be the following:

Success!

Now I am fully aware this is only decorating one function on the concrete component. But there is no reason you couldn’t make the Class Decorator (in this example the SimpleClassDecorator) have multiple Action<T> (or Action<T, S> …, or even Func<T, TResult> if you need return values).

In most cases however, there is mostly one entry point into making a class start doing something. Keep in mind, while the SimpleClassDecorator class may look somewhat ugly (because you are encapsulating the block in a delegate), it pays off when you call your decorators. And you only have to write one SimpleClassDecorator, but you can write tons of Decorating Extension Methods to decorate your concrete component object, that actually look quite easy to make going forward.

Anyways, this certainly isn’t the only way to do a Fluent Decorating Pattern, but it was my first attempt at 2am in the morning (I hate it when I think of something in the middle of the night and need to figure it out).

Also, it’s worth noting that this would also be trivial to do the same thing in Ruby, just using blocks.

Utilizing Ninject with ASP.NET MVC Framework

Lately, I have been using ASP.NET MVC exclusively on a lot of projects and have been looking for a clean way to enforce the DIP (Dependency Inversion Principle) utilizing the Strategy Pattern throughout my applications. If all of these terms seem alien to you, then you should really look into reading about them. If you want to write highly maintainable code (that is subject to spec changes every month), work very little to achieve this, and in general have clean code, these principles will go a long way to helping you out. Also, once you start doing things this way, you will never want to go back to the old clunky way of over-inheritance, and coupled-ridden code. Before you go farther, if you don’t know what these things are, do your-self a favor and Google “Dependency Inversion Principle” and “Strategy Pattern” and do a quick read on the subject. Once you get the hang of these ideas, a Dependency Injection Framework (also referred to as Inversion of Control Containers), essentially helps you very quickly enforce and setup your DIP throughout your code seamlessly and effectively. It’s a tool to help you achieve this principle and pattern throughout your code.

So after playing around with several Dependency Injection (DI) Frameworks (Unity, Spring, etc) I finally settled on one that I instantly fell in love with because of its simplicity, speed, and complete flexibility: Ninject (www.ninject.org). It is by far one of the simplistic dependency injection frameworks I have found, and fits within how I like to do things. A lot of other DI Frameworks want to be setup through a configuration file (most likely XML) to state how to handle casting and creating of your abstractions to concrete classes. However, Ninject is all about coding modules to setup your dependencies (which you can refer to configuration files there if necessary). It is also completely open so that you can modify and build on it to suit your needs.

Now don’t get me wrong, there are several great DI Frameworks out there, so before you flame me, here me out. DI Frameworks are like opinions, people have several of them. Each person thinks theirs is the best, and you cant tell them any differently. The beauty here is that you just use what works for you. The ideas I will post here should be usable through-out any DI Framework with some massaging.

So, back on course, I wanted to write a blog post about using the Dependency Injection Framework Ninject with the ASP.NET MVC Framework. I utilized it in a standard ASP.NET Web Forms project and it work as advertised. Let us take a real quick look into how it looks (if you really want to see what it is all about take a look at these URLs (http://dojo.ninject.org/wiki/display/NINJECT/Home , Screencast by Justin Etheredge: #1 Introduction to the Ninject IoC Container #2 Diving Deeper into Ninject -- Contextual Binding )

Lets start with the common MVP Pattern in a Classic ASP.NET Web Form application and then when we understand those concepts, apply it to a ASP.NET MVC Web Application.

Typically you will need to setup a Module to define how Ninject should handle your Abstractions to Concrete classes:

In this example I am telling Ninject how to inject my abstractions IRepository and IService to what Concrete class I want it to be (the AppHelper is a static class that handles grabbing which configuration details are needed for my application – similar to how Rails does this). You can see the syntax is very readable. You simply tell it that you want to bind this abstraction to this concrete type: Bind<AbstractionType>().To<ConcreteType>(). The only weird one up there is the Bind<PagePresenter>().ToSelf(). This one is simply telling Ninject that if I ask you go give me this type, just instantiate it (you could also specify default constructor parameters for Ninject to use, or when you want it to make it). You could have just omitted this, as it does this by default, but I like to be explicit in my rules.

There is no voodoo going on here. To further clarify what is going on and how it handles creating these abstractions to your concrete classes down the chain, let us look at a brief implementation of the presenter, service, and repository classes (because when we create instances of it we will be creating a Presenter, that will in turn need a Service, that will in turn need a Repository implementation instance):

Presenter:

Service:

Repository:

As you can see, using MVP (Model View Presenter), in the view we will need the following:

The only piece necessary now, is to set your view (or you can simply use NinjectHttpApplication for your Global.asax.cs and PageBase for your View located in Ninject.Framework.Web) to load up your Presenter using Ninject:


The injecting of the this object on the view will see the Property with the attribute “Inject” and start the chain of creating all of your concrete class instances from looking at the Abstract type it requires (using the Module we defined earlier). We didn’t have to write a single new line in our code, Ninject handled all of this for us.

Ok, so it works really nice in ASP.NET Web Forms, but what about ASP.NET MVC. Well, this is where it required me to extend Ninject, as it doesn’t add helper support to ASP.NET MVC that fits nicely in the ASP.NET MVC style of doing things.

Typically as you saw above, we get the view to inject all the way down the tree of instantiations. What you didn’t see is you can use Ninject.Framework.Web to help in your Global.asax class file (by changing it from HttpApplication to NinjectHttpApplication) to handle a lot of this setup for us, and make your Page inherit from PageBase to auto-inject the view and start it down the chain.

So how would we do this in MVC? Well you could do the same thing with the Global.asax file and make a base Controller class to inject the controller instance object, or you can do it the MVC way, and make it nice and clean.

So what is one way to do that?
I am glad you asked. First I had to think about how a classic ASP.NET page works using the MVP pattern and how it works using the MVC pattern. The classic ASP.NET page request first comes to a web page, so the view is the one to get the initial response, so it makes sense to start the chain of injections from there on down. But in MVC, the request first comes to the Controller, so logically we need to start the chain of injects starting there. The most effective way to do this (without tying the Controller to a base class of say NinjectControllerBase – in case we want to utilize some swanky open source ideas out there that need this) is to use a controller factory to handle all of this for us.

Here is such an implementation of one (keep in mind that KernelContainer is located in Ninject.Framework.Web, and the bottom code would be put into a dll that you can add to all of your MVC applications) :

So what does all of this allow you to do? Well assuming you package up the above into its own dll (say Ninject.Framework.MVC), you can just add it to your project and do the following to add Ninject support to your application.

1) Use the simple default Ninject controller factory to add in support in your Global.asax file in the RouteTable function.

2) Make your own Controller Factory and inherit from NinjectAbstractControllerFactory and just override CreateKernel (this is where you would make a new Ninject Kernel with the Module we created early on), then in the Global.asax file add it when building the routes for you MVC application.


As you can see here you can call it 2 ways. If you don’t care about utilizing a Controller Factory, then you can just use the first method, that builds the controller factory for you and sets up your injections for all controllers for you. You can alternatively make your own that inherits from the above NinjectAbstractControllerFactory. You can chose how you want it to load.

This is a great way to have IoC/DI in your MVC application without getting in the way of your other code. You set it and your rules and forget about it. From there you can just start marking up “[Inject]” to those constructors, properties, etc you want Ninject to take care of.

This example will load DataService and the Repository (in the IService implementation) that we specified in our module. Similar to how it worked in the MVP pattern mentioned above, except our Controller Factory did all the setup for us behind the scenes and tucked away.

Feedback, questions, comments. Keep in mind this is merely one approach, there are several others that can be taken, but I like this one. I have used it on 3 projects so far, and it really is efficient and simple to setup.

If anyone knows of a good place to store code, I can zip up all of this code and make a simple example for you to play with and tweak to how you would like it to work.

For now, as per suggestion, you can copy the above code (the Factory Code) from google docs here.