MVC

[zyx]

Hello all,

    I am trying to understand the MVC pattern (again). In my original understanding the View Layer represents the system interface and basically communicates the events to the control layer. The control layer should interpret the events and call the appropriate methods defined in the classes of the model layer and pass the results to the view layer. The model layer contains the classes representing the problem domain and containing the business logic methods.

    But I saw other texts and examples where the classes classes have only attributes and getters / setters methods and the logical business was placed in the control classes. It confused me and I thought I was modeling in the wrong way. But keep searching and I read texts that asserts the model layer must contain the logical business methods and entities that  have only getters / setters methods are "anemic" entities classes.

    So I ask, what is correct? In a bankary system, by example, methods like openAccount, deposit and withdraw should be in the model layer (I think so) or in the control layer?
 

[qwerty]

In "pure" terms the controller should have the business logic. And that makes pretty much sense. The view should just serve the presentation of information respectively it should get information from the outer world (the user interface). And the model should just store persistent data. There are different newer flavors of MVC like MVP. Also there are sometimes needs that force deviance from the dogmatic way.

q.

[Sunshine]

Martin Fowler has written some good stuff on patterns and the UI architecture patterns can be found here
http://martinfowler.com/eaaDev/uiArchs.html

[zyx]

Hello,

    Thank you for the help. The link that was posted, as I understand it, appear to say that the logical business must be in the model layer and not in the control layer. And in this link: http://www.martinfowler.com/bliki/AnemicDomainModel.html    the author Martin Fowler talks about the "anemic classes" that are classes only with attributes and getter/setter methods. He claims it is not correct and that the business logic should be in the model layer and the controller should only interpret events in the view layer and call methods in the model layer. Still I found texts that claims that the correct is to build skinny controllers and fat models... But there other people and texts that say the contrary...

[Sunshine]

Remember patterns are ideas of how to do things that have consequences and that you often have to mix and match or modify in various circumstances. Your problem may be the same as what Martin is suggesting so a fat model may be valid. On the other hand you may have different circumstances in which case MVC plus something else may be a better choice. Don't know what your problem is so can't provide advice however, I've found Martin Fowler to be one of the pioneers of thinking in patterns and have a number of his books. This particular book was one of my favourites and is worth getting a copy to gain a more comprehensive understanding of enterprise application patterns. Suggest you get a copy and read it to gain a better understanding.
http://www.martinfowler.com/books/eaa.html

By the way referring to an earlier post on this thread, Martin Fowler retired the  MVP pattern some time ago.
http://martinfowler.com/eaaDev/ModelViewPresenter.html

Another useful link for a more comprehensive list of patterns can be found here
http://martinfowler.com/articles/enterprisePatterns.html

Don't think of MVC being split into layers M, V and C that isn't correct. In an n-tiered system all MVC objects belong in the UI layer. The business layer would have the business logic and the data layer would have the storage.

Hope that helps

[ChrisMW]

I see a lot of MVC variants. The original I know of comes from Smalltalk. The model represents business and views present parts of the model to the user. Controllers handle events from the user. The objective is to isolate the model from its surroundings, in order to promote reuse of the model. Therefore it follows that:
a) the model knows not of the controller nor the view
b) the view knows the model
c) the controller knows the model
d) the controller knows the view.

In Smalltalk, it was very uncommon to create bespoke controllers, you used the ones that were there. They were tied to input channels, not applications. So you create your model and your views and tie it together in an app. The confusing part is that once a controller updates part of the model, the model should trigger the views to update. This was done through a 'broadcast'. It's a bit like a publication/subscription or broadcast. The model just says 'I've changed' and the views should then update with the latest model data by accessing the model. I forget where that is handled, but I think you do that in the setup where the views/models and controllers are tied together. It's been a while. But the rule was that the model never knew the view instances and did not know if any of the views updated itself.

An excellent remark was made on tiering, the original MVC (before it was even called a pattern), was a single large blob app environment. You can apply MVC to a front-end and back-end, and in each case the model is somewhat different. But on the basis of the original idea, the model of the back-end would be one you'd want to isolate from its context more than the model in the front-end.

So I would not think the controller is the perfect place to place business logic. I would say it's the model. I used to work for an IT company that found the MVC model lacks expressiveness and they created the 5-component model. (way back in the 90's) It is somewhat like the MVC model, but has a spot for data storage (i.e. the generic bit of your ORM or DB access code) and a spot for delegation work, and works more intuitively in practice.

MVC is not a bad pattern, but as with all patterns, their usefulness really depends on what you need the benefit to be. MVC's benefit was to allow you to yank model classes from one app and put them into another, without having to drag other stuff across as well. Basically business logic should not be tied to a specific application. Views are by definition tied to an application. So don't tie business logic to views. Same for controllers, essentially commands and some business state changes. The commands need to be responded to and business state changes sent to the model. So it's fine to bind input/output to a model, but don't bind the model to particular input/output so you can leverage the model. After all, reuse is best if I can simply create a class and tell it 'do this'. So MVC tries to help you make pure business classes. Not bad for 1969