Where my Business Logic should be?

[marogalli]

Hi guys.
In Siesta documentation I found :

• 1.Test the model first : You may already have heard the "fat model, skinny view" idiom. It means - put as much of business logic in the Model, don't pollute the View with it.
  2.Test views (individual components) after Model
  3.Test the application as a whole.

I'am migrating my Exjts3 App to 4. I am trying use the best of MVC and TDD but I cannot understand this above. How it is possible to control Bussiness Logic from UI on Models? The user input is controlled by my app and I just call the backend when it is correct. For example, if the user does not fill on field, the app shows an error, and for me this is the business logic (cannot send empty textField).

I have a lot of DataView in my project, and it has different behavior depending on data returned. This is also a business logic that must be on my View. Due this I am migrating my app but It looks like skinny model and fat view and controller(due GUI business logic), as events are controlled in controllers, I mean, all UI business logic. I realize some events is better treated in View component(object encapsulation), instead of using the controller to treat them, one example is DataView.

What I'am supposed to test in Models? Testing gets and sets it is in my opinion not necessary, since Sencha tested it, and it is supposed to work. I don' t want to test what is supposed to work and what have been tested by Sencha, for example, In forms the "allowBlank: false" is not tested by me.
It is great to test everything, even the Extjs framework to be sure everything is OK in all browsers, but now I am testing my logic and believing the framework works as expected. Does that make sense?

In my understanding the MVC pattern is different from server side and web client, due the nature of the UI.

Am I crazy in my thoughts?

I hope I use Siesta with CI server soon(and dont have CI yet ). Thanks for the excellent job! I am loving it!

Thks

[nickolay]

Thats correct, put your business logic to your model and keep you views skinny

Under business logic we usually assume something more advanced that requirement that some field can't be empty (that's also a business logic of course). Lets say you have the Employee model and you have some form in which you will be calculating the monthly paycheck for him, based on various flags.
The idea is, that `calculatePayCheck(params)` should be method of the Employee model (case 1), not the EmployeePayCheckForm (case 2).

In the first case, `calculatePayCheck` is part of the model. You can easily cover it with tests, w/o instantiating any UI components, dealing with browser quirks etc. After that you will be sure this method works correctly, and when writing the UI you will concentrate only on UI.

In the second case, to write a test for this method, you need to instantiate the form, then, imitative user actions to fill it with data, and only then check for result. Much harder, especially for complex forms and considering all differences/edge cases across browsers. This kind of testing is also important, but I'd recommend start writing such tests only after you've covered your model.

[marogalli]

I agree with you, but there are some Views that has more complex business logic. My DataView UI has for different types of rendering depending on store return.

And also the controller must have logic from all actions.

Usually my logic is in my backend, and all the logic I am testing is user interaction logic.

Well, I think I'am going the right way.

Tnks for you replly and help.

[jakub]

Reason to keep logic in controller is also because views are refreshed, whilst controller not, so it may be heavier.