Question

At work we’re about to re-write an old application and I was told to get some ideas about how we could do it.

My idea is the following:

Since the application will be mainly a website I’d use MVC. EF with POCO entities for DI and IoC. WCF for the services that the web app and other clients will be consuming.

So far the architecture should look like this:
– Demo.Web
– Demo.Entities
– Demo.Services

Now my architecture looks like this:

namespace Demo.Entities

// IEntity.cs
public interface IEntity { }

//User.cs
public virtual long UserId { get; private set; }
public virtual string Name { get; private set; }

public User() { }
public User(long userId, string name)
{
    UserId = userId;
    Name = name;
}

namespace Demo.Services

// IService.cs
public interface IService<T> : IDisposable where T : IEntity
{
    List<T> GetList();
}

// UserService.cs
public class UserService : IService<User>
{
    public List<User> GetList()
    {
        return new List<User>(); // Simplicity
    }

    public void Dispose() { }
}

When I need to use this I would do:

using(IService<User> service = new UserService())
{
    var q = service.GetList();
}

As for MVC, I will use the models from Demo.Models, and if need to have the actual models I will link them to my Models folder of my MVC application, but now MVC is my last concern.

So far I’ve detected one issue, I won’t be able to query multiple entities without instantiating the specified service. On the bright side I have full control of what and how my data is being handled.

Actual question

If any, can anyone point me to any architectural design to support these features?

Answer 1

I am a big fan of the SOLID architecture principles described here and here. They are worth checking out and spiking before you make a final decision. DotNetJunkie will also be posting another blog entry about how to use these patterns with WCF sometime in the not-too-distant future. The interfaces and patterns he describes are decoupled enough to use them with either EF or NHibernate.

One concern I see with your post is the IEntity interface. I don’t think you need to have an interface for your base entitiy, usually an abstract base class is enough (i.e. using the Layer Supertype pattern). I have never found a reason to make all entities subscribe to a single interface contract.

I also don’t see any dependency injection in your examples. Any code that uses using(IService<User> ctx = new UserService()) is taking a dependency on the interface AND the implementation. You want your MVC or other client code to take a hard dependency only on the interface, and have concrete implementations resolved/injected by your inversion of control container. This is a pattern that is common in the Onion Architecture that trailmax posted about.

I do like your idea of having a “tripod” of projects. Try not to let the project count in your solution get bigger than about 5 projects though (excluding unit test projects, those don’t count).

So far I’ve detected one issue, I won’t be able to query multiple
entities without instantiating the specified service. On the bright
side I have full control of what and how my data is being handled.

Again these concerns can be handled by reading and adopting the ICommandHandler and IQueryHandler / IQueryProcessor patterns described in the articles I mentioned above. You do not have to instantiate any services at all. You just constructor-inject either IQueryProcessor or ICommandHandler<TCommand> into your controller, and let the IoC container provide the implementation. If you have an operation that needs to query multiple entities, you just do that by accessing either EF or NHibernate in your query’s Handle method.

Here is an example of one of my projects that uses these patterns:

MyApp.Domain.csproj

Class library that contains all entities as well as the DotNetJunkie interfaces, and command + query implementations. This takes no dependencies on Entity Framework or any of the other projects.

MyApp.Impl.csproj

Class library that contains implementations of interfaces, as well as the EF DbContext and the IoC container. This takes dependencies on the Domain project as well as EF, the IoC library, etc.

MyApp.Mvc.csproj

The MVC project takes dependencies on the other two.

This is a very basic example of the Onion Architecture.