MVC pattern differences

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

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 FindOne(int id);
    IQueryable GetOne(int id);
    IQueryable FindAll(Expression> predicate);
}

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

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

The all other interfaces look like this:

interface ICategoriesRepository : IReadCreate
{
    IQueryable 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 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().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). 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.