Mvc4: N tier architecture

Question

Tools: Mvc4, Sql server, Nhibernate

I am learning Ntier architecture and plan to learn this with a small example. This will be a student registration application which will have a form for a. first name b. last name c. address d. Student Id The application will be able to a. Get student by Id b. Get all students c. Register new students/Save student d. Edit a student e. Delete a student

I plan to have the following tiers

Presentation layer (seperate project mvc 4 application)

--- html for student form goes here. I can use jquery etc here --- my controller will call the service

Service layer (seperate project : class library project. In this case only the web will be my client. I will learn to use webAPI or wcf for this later in another project)

--- StudentService here

--- IstudentService here

Business layer : (seperate project : class library project) ??

Data layer : (seperate project : class library project) ??

Database : (sql server database)

Now I got confused and my questions are:

1. where will I create my student model (which layer ?)

2. What will I be writing in my business layer for this student example I have.

3. What will go in my data layer? Which methods will I be writing? Are they methods that will communicate with the database directly?

   Some examples will be great. I will look for a good IOC container.

Here is sample code below:

public interface IStudentService

    {
        IEnumerable<Student> GetStudents();

        Student GetStudentById(int id);

        void CreateStudent(Student student);

        void UpdateStudent(Student student);

        void DeleteStudent(int id);

        void SaveStudent();
    }

public class StudentService : IStudentService
    {
        private DataContext _datacontext;
        public StudentService()
        {
            _datacontext = new DataContext();
        }

        public IEnumerable<Student> GetStudents()
        {
            var students = _datacontext.Students;
            return students;
        }

        public Student GetStudentById(int id)
        {
            return _datacontext.Students.Find(id);
        }

        public void CreateStudent(Student student)
        {
            _datacontext.Students.Add(student);
            _datacontext.SaveChanges();
        }

        public void UpdateStudent(Student student)
        {
            _datacontext.Entry(student).State = EntityState.Modified;
            //_datacontext.Entry(student).State = EntityState.Modified;
            _datacontext.SaveChanges();
        }

        public void DeleteStudent(int id)
        {
            var student = _datacontext.Students.Find(id);
            _datacontext.Entry(student).State = EntityState.Deleted;
            _datacontext.SaveChanges();
        }

        public void SaveStudent()
        {
            _datacontext.SaveChanges();
        }
    }

Answer 1

You need to have a look on Onion Architecture. It is a bit out of date in terms of MVC versions, but the tiers are layered greatly.

In terms of IoC container I'd recommend looking on Autofac - easy to use with a lot of features, like registration by conventions and multi-tenant.

As for your questions:

What I usually have is on form submit, controller would get a StudentViewModel submitted, then I would convert it to a Student object and hand over to IStudentRepository that is injected into the controller. And IStudentRepositry will save it to the DBContext. The repository interface would sit in Domain layer, but implementation of the repository would be in Data layer. And DI container will match one to the other.

The trick here is to have all interfaces in Domain layer and implementations sitting wherever they should be. And Domain layer should not be dependent on any other layer (read Domain project would not have reference to Data and Web projects). But Web would depend on Data and Domain layers. You only need Data layer dependency in Web layer to configure IoC container, as web layer is your aggregate root, and IoC should be configured there. But you should never use Data objects directly in any of the operations, you should be injecting interfaces for repositories or services.

There is a lot have been said about the layered architecture, so start with Onion Architecture first, then you'll have a better idea of what you need.

Answer 2

1. You create your model in your data layer. You will also create models in your presentation tier (for your view models). You would usually do some kind of mapping between your data model and your presentation model in your controller.

2. Simple apps often don't really need a business layer. Particularly if your app just saves data from forms into tables. However, in an app such as this you might do things like "You can't register for this class unless you've already completed that class" or you might have "You have already registered for more classes than you are allowed" or what not. These are business rules that must be enforced somewhere, and that is usually in the business layer.

3. Your data layer will probably just be your Entity Framework model. It's just your code to load and save your model to the database.

There are many IoC containers.. I like Ninject, but other people like other ones.. It's generally a matter of personal preference.

The above is how you would do it in a simple application. In more complex applications, you might have a model in your business layer as well. It all depends on the complexity of your application, and whether you need to represent your data at a business level differently than you would at a data model level.

For instance, you might have a list of business objects in the business layer, but these objects are represented differently in your data layer for performance reasons. But all of this is really not things you should worry about at this point. Just understand that as your applications become more complex, you may have the need to do things differently.