Question

I just need a few links to articles I can read up on or some basic explanations regarding the different patterns used in MVC (C#).

At present I tend to build my web apps using a view model pattern. For every view I have one view model. I like this approach purely because there can be so much junk that is not needed from the model and I can use some basic data annotations here.

I also now construct my viewmodels within the view model itself (Unsure if this is correct?) so that I can keep my controllers as simple as possible.

There are times however I have found myself adding in a lot of logic within my controller, I would assume this is fine also as to me that is what the controller is there for.

Now based on the above as I said I can quite happily build my apps without any major issues. However whilst doing my normal browsing of code examples etc I often find that there are so many other ways out there used by different developers to do essentially what I am doing above and I would like an explanation of they all fit together.

I often see mentioned “use your repository to do blah blah”.. I do use repositorys “sometimes” but this is mainly for model querying that I know I will re-use in the future and it always turns in to a bit of a dumping ground. What is best practice here?

I also see mentioned “interfaces” and “service layers” I am totally lost here.. most examples to me seem to just be adding more and more steps to achieve the same goal. How/why are they used?

Answer 1

I can’t say this is the best practice, but this is what I use, and why, and here we go:

---

1. The repositories.

They are structured this way:

There are three basic interfaces, IRead<>, IReadCreate<> and IReadCreateDelete<>.

interface IRead<T>
{ 
    T FindOne(int id);
    IQueryable<T> GetOne(int id);
    IQueryable<T> FindAll(Expression<Func<T, bool>> predicate);
}

interface IReadCreate<T> : IRead<T>
{ 
    T Create();
    void Create(T entity);
}

interface IReadCreateDelete<T> : IReadCreate<T>
{ 
    void Delete(int id);
    void Delete(T entity);
    void DeleteWhere(Expression<Func<T, bool>> predicate);
}

The all other interfaces look like this:

interface ICategoriesRepository : IReadCreate<Category>
{
    IQueryable<Category> GetAllActive();
}

And all of them provides additional usefull functionality on the data source they depend on. It means, I cannot reach other typed repositories in my implementation repository. That should be done on Services. (Look below.)

The main goal of this approach is to show the calling code (from another assembly, because all my repositories, services and other contracts are defined (as interfaces) in separate DLL project) what it can do (like reading and creating items) and what it cannot do (like deleting items).

---

2. Services

Services and best way to implement your business logic. They should implement all your vital logic methods. To achive that kind of implementation they will need some repositories depency, and here it comes the Dependency Injector. I prefer to use Ninject, because it allows me to inject dependency properties like this:

internal class CategoriesService : ICategoryService
{
    public ICategoriesRepository CategoriesRepository { get; set; }
    public IWorkstationsRepository WorkstationsRepository { get; set; }

    // No constructor injection. I am too lazy for that, so the above properties 
    // are auto-injected with my custom ninject injection heuristic.

    public void ActivateCategory(int categoryId)
    {
        CategoriesRepository.FindOne(categoryId).IsActive = true;
    }
}

The goal of services is to eliminate business logic from controllers and from repositories.

---

3. ViewModels

Cool thing, as you told, but the reason is why are you building them up in theirselves is the thing I can’t get. I am using the automapper for that (with its queryable extensions), which allows me to create views like this:

Let’s say I have a view which needs an IEnumerable<TicketViewModel> model. What I do is:

public class FooController : Controller
{
     public IMappingEngine Mapping { get; set; } // Thing from automapper.
     public ITicketsRepository TicketsRepository { get; set; }

     public ViewResult Tickes()
     { 
         return View(TicketsRepository.GetAllForToday().Project(Mapping)
             .To<TicketViewModel>().ToArray();
     }
}

That’s it. Simple call to repository, which makes calls to underlying data source (another pattern. I wont write about it, because its abstraction is needed only for testing.), which makes calls to database (or whatever you implement IDataSource<T>). Automapper automappically maps the Ticket to TicketViewModel and form database I retrive the only needed for my ViewModel columns, including the cross-table in a single request.

---

Conclusion

There are much to say more, but I hope this will give you some food for thought. All the patterns and programs I use are:

1. Automapper (mapping);
2. Ninject (dependency injection);
3. Repositories (data access);
4. Data Source (data reads from .. well.. from data source);
5. Services (data interactivity);
6. ViewModels (data transfer objects);
7. Maybe something else I’ll edit to add about.