-1

I have been doing Java and Ruby (and used frameworks) for some while and I know MVC is a way to separate code. The thing is, I think I never really used it in the way it should.

The first question is: Business logic, what does it mean? Does Business logic mean the logic that is special for that application? Let say you are building a Satellite system. Is the business logic the code that is unique for that Satellite system and make it work?

What does "domain" mean? Like in domain logic or domain as a term.

"Keep your model smart, controllers thin and view dumb". This statement clearly indicates that the controllers which I load with too much code is the wrong way of writing it.

As an example. If you have a BankAccount class. Then should this class provide methods for behavior such as validating etc as well as getter/setter?

What should the controller be doing? Just redirecting input/events in the view to the model and maybe update view (which is the case in webframeworks).

For example in Java and JPA you have the entityManager that you use for finding entities, maybe do something on them etc. Should this entitymanager be used in the controller, or should you make another layer named e.g. "Service" which the controller uses. But again, does this server layer then belong to the Model in MVC? How would you do this in Rails?

I don't get the Model nor the Controller concept right I think.

DNA
  • 42,007
  • 12
  • 107
  • 146
user626912
  • 2,546
  • 3
  • 24
  • 33
  • read http://stackoverflow.com/questions/8692965/what-is-the-actual-pattern-for-mvc-wrt-webapplications – ThinkingMonkey Feb 10 '12 at 15:18
  • possible duplicate of 1] http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference 2]http://stackoverflow.com/questions/26685/what-is-mvc-and-what-are-the-advantages-of-it 3] http://stackoverflow.com/questions/2626803/mvc-model-view-controller-can-it-be-explained-in-simple-terms and many more – ThinkingMonkey Feb 10 '12 at 15:21

1 Answers1

2

Think of applications as being layered. When working on each layer, always think to yourself, "Is this layer dependent on the layer above it or can it work independently?" That is the basis to a good MVC application.

When thinking of layers in an MVC style application, there are a few.

In my mind the layers (from top to bottom) are the view, controllers, business logic, and data access.

The view could be JSP or even AJAX requests from jQuery. This is where the user interacts with your application. The view sends information to the business logic layer to do work.

Controllers should be written to collect data sent to it from the view, transform it in a way that the business logic can understand it, and then pass the information into the business logic layer. Controllers may also take information retured from the business logic layer, transform it, and send it back to the view. No real "business logic" should happen here. Think of it as a broker between the view and the business object layer. This is also a great spot for validating data submitted by the view.

Business logic is a layer you would find in the middle, typically between the controllers and data access layer. This could also be called a service layer. It should be written to not know anything about what is calling it. If written correctly, you could use this layer in a standalone application. Here is where a lot of the application smarts should take place. A lot of times, this layer is simply here to call the data access layer and return the results back to the controllers. But, a lot of other things could go on here like data manipulation, calculations, data security, validation, etc.

The data access layer should be written in such a way that it takes it's input, retrieves the appropriate data, transforms it into a useable form, and returns it. This layer should not know or care what is calling it and should be written in that way. Again, this layer should not know it is in a web application or a stand alone application. There are a lot of options here to make your life simpler in the form or ORM (Object Relational Mapping) frameworks. If your application is a step above trivial, you should think about using one.

In the traditional sense, the model could be the business logic layer and the data access layer as well as the domain objects that go along with them.

Using "BankAccount" as an example:

"BankAccount" sounds more like a domain object (representation of data in a database) than a class that has logic in it. Typically domain objects only have the fields they need (account number, balance, etc.) with getters and setters.

The user might log into their bank website. On login, the view sends the username to the controller (BankAccountController). The controller takes this information out of the request and sends it to the service layer (BankAccountService). The service layer would send this information to the data access layer which does a query for the BankAccounts that the user might have and return them to the service layer which returns them to the controller. The controller will manipulate this information in some way that the view layer can display them to the user. There would be a similar series of events when the user transfers money between accounts, for instance.

Hope this helps... let me know if you have any more questions or if something isn't clear.

Edit:

Besides the links posted by the other users, Wikipedia has a brief, but pretty good article on MVC.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

B. Anderson
  • 3,079
  • 25
  • 33
  • Thank you for your time of making this answer:) I think I understood it a little better but you talk about validation in both the service and controller layer. What is the difference? Also after what I understand the domain object, service and data access layer are the M in MVC. Is it normal to make such layers in Rails(where do you put the classes)? I know data access is provided by the framework as active record but I am thinking of the service layer. – user626912 Feb 10 '12 at 18:59