Separation of concerns between model and controller

Question

I'm still trying to understand this whole separation of concerns and one thing I dont understand is difference between model and controller in terms of data modification.

Suppose I have a simple model:

public class BankAccount
{
    private decimal amount;
    public decimal Amount
    {
        get
        {
            return amount;
        }
        private set
        {
            amount = value;
        }
    }

    public BankAccount(decimal amount)
    {
        Amount = amount;
    }

    public decimal DepositMoney(decimal amount)
    {
        Amount += amount;
        return amount;
    }

    public decimal WithdrawMoney(decimal amount)
    {
        Amount -= amount;
        return amount;
    }
}

I believe this is what the model is all about. But, where do I call these methods? Is it inside a controller? Can I modify data there? For example, if I want to transfer some money from Jim to Joe; would I call this method joe.DepositMoney(jim.WithdrawMoney(25)); from the controller? Or should I create a method for transfering money in the model and call just this method?

Answer 1

A model should have functions related to his own functionality. You could have a Function Transfer that receive another account.

Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI

You should use this methods in your controller. Anyway i suggest you keep your project SOLID, if your project grow (and they grow fast) you will has a lot of logic done in your controller and will be very hard to resolve bugs.

You could have services to keep the logic outside controllers and controllers use this services. Anyway this is a very simple approach. I suggest you read books like: http://blogs.msdn.com/b/cesardelatorre/archive/2010/03/26/our-brand-new-ddd-n-layer-net-4-0-architecture-guide-book-and-sample-app-in-codeplex.aspx

You will get a lot of concepts and idea that can help you for the future.

Then most important is to had a lot of tool and use the exact who fit your problem.

Answer 2

This link should help you understand better:

http://tomdalling.com/blog/software-design/model-view-controller-explained/

In Summary, the Model handles Data related operations, the Controller handles actions such as user inputs, calculations (in your case), conditions, etc and the View presents formatted output to the user.

I hope this helps.

Answer 3

basically what the controller does is glue the presentation layer (the view) to the backend layer (the datamodel).

In seperation of concerns, a view should never know about the model , neither the model should know about the view. the only connection between them is the middle layer which is the controller, so if you want to transfer or update money, it has to go from the view, trigger an action in the contoller, and the latter tirggers a database operation in the mode.

Thanks

Answer 4

ASP.NET MVC is a framework that uses the Model-View-Controller (MVC) pattern.

"Seperation of concerns" essentially means -

1. Data (business logic) [Model]
2. Visual representation (HTML, etc) [View]
3. Control user actions [Controller]

You can think of the Controller as the middle layer which communicates with the Model and View.

The methods in your example would be called in a Controller.

For example:

public ActionResult Example()
{
    BankAccount Model = new BankAcount(20);
    Model.Variable = Modify.Me;
    ...

    return View(Model);
}

So when the Action Example is called, a new instance of the BankAccount Model will be created and a View (that is, strongly-typed to BankAccount) will be returned.

Yes, you would call that method joe.DepositMoney(...); from within the Controller. Remember that HTTP is a stateless protocol, so this data will be discarded.

Many applications use Services to handle data manipulation (e.g. accessing a database).

Answer 5

There seems to be a lot of confusion about Models and View Models. The main point of MVC is that

1. You have a controller (class) that has actions (methods). Actions respond to user input (HTTP requests, for one).
2. The controller generates some object containing the data needed to be rendered - this object is called View Model. View Model defines what must be rendered but not how it should be rendered.
3. The View Model is passed to a View. View is responsible for "wrapping" the View Model and generating something to present it appropriately - usually it generates HTML markup.

And that's what ASP.NET MVC is all about, actually. You have a controller, you create a View Model, you pass it into the View and View generates some presentation.

Model, however, is a very confusing term. It is generally used to describe the source for View Model data. The good practice here is to let all the logic be handled outside the controller; to do so, you should have a service layer. Services should basically fill in the role of generating appropriate data for View Models and perform appropriate logic, when necessary. So, in summary, this should look like this:

1. Controller reacts to user input, determines what exactly happened and passes all relevant data to appropriate service.
2. Service contains all the logic and generates data that may be used to respond to user input.
3. Controller uses this service-generated data to create a View Model.
4. The View Model is passed to the View and rendered appropriately.