Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
May 29, 2017, 08:21:42 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
Pages: [1]
Print
Author Topic: Business logic in Controller  (Read 5903 times)
eliatlas
Jr. Member
**
Posts: 19


View Profile Email
« on: March 26, 2012, 03:08:26 AM »

Hi Forum

During my reading about MVC, I encountered a term that I found interesting.
The term is  Fat Stupid Ugly Controllers (FSUC). It belongs to Pádraic Brady, who is pretty famous in PHP community.
He has a pretty cool book about Zend framework, and he wrote a chapter about MVC http://bit.ly/GQrmwJ .

His idea is that controllers should be as thick as possible and our business logic should be in the Model.
In PureMVC we have a separation for Business Logic and Domain Logic, and the best practice is maintaining BL in the controller
and the DL in the model.

So I have two question:
1 - Is PureMVC using a different approach to Controller role, different from classic MVC?
2 - Is the reason for it is AS3, and the fact that the language is multiplatform?

Thanks,
Eli
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2867



View Profile WWW
« Reply #1 on: March 26, 2012, 08:05:17 AM »

PureMVC originated and is used (mostly) on the client-side, though I'm not suggesting its use on the server-side should follow different rules).

Business logic is the logic that carries out the unique aims of a given program. However the Model, particularly on the client-side is often reused.

For instance, at the moment, I'm working on an app for a client that started as a Flex/web-based presentation creation tool. But we needed a lightweight viewer to share  these presentations with casual users. So we created a Flex/web-based viewer. We shared the Model, but the business logic is completely different. Then we needed a desktop version of the viewer that could cache files for offline viewing. Again, we shared the Model, but as you can imagine, the business logic varied a bit (we shared some, but not all of it). Then we needed an iPad viewer. Once again, we shared the Model, but the View and business logic changed considerably (although some of it was still shared with the other viewers). Then we needed an Android version of the viewer. Wash, rinse, repeat.

So in all of these apps, the Model is constant. The viewer apps don't need business logic that is related to the creation tool, which includes things like creating libraries of media and assembling them onto slides and so forth, but if we put all the business logic in the Model, that's what we'd have.

Quote
1 - Is PureMVC using a different approach to Controller role, different from classic MVC?
No. Classic MVC doesn't say you should put all your logic into the Model. In fact, it's the opposite; it suggests the Model should be passive, or at most manage the manipulation of its data and notify the rest of the triad of changes. Here is one of the earliest papers on MVC: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

In PureMVC, the Model region takes on the added responsibility of communication with the server on a client-side app (or with databases or other datasources on a server-side app), so as to encapsulate all access to the Model data in one region. So it is somewhat more active than the classic MVC Model, but not by much. With regard to interaction with the Controller and View regions, it is the same. It can notify, them but that is all.

Quote
2 - Is the reason for it is AS3, and the fact that the language is multiplatform?
This stuff about business logic going into the Model is a server-side perspective. You don't typically share the Model around between apps on the server, and when you're interacting with a database, there is often lots of messy logic involved, but that doesn't mean that the business logic needs to go there. The distinction between Domain and Business logic is one that should be respected regardless of whether you're using PureMVC.

One thing to remember about PureMVC is that we don't write Controllers, we write Commands. Controllers in other frameworks often become monolithic, all-knowing God Objects, and that is not good. But with Commands, we have tiny little bits of logic that deal with one slice of a use-case's path through the system. We don't suffer from FSUC, even if our app has lots of Commands. Another thing to keep in mind is that every use-case doesn't have to pass through the Controller region.

In strict, three-tier architecture (http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture), each time the View accesses the Model, it must do so by going through the Controller. And each time the Model needs to notify the View, it also goes through the Controller to get there. But with MVC (http://en.wikipedia.org/wiki/Model-view-controller), we do not have that constraint, although you can write your programs that way if you like, but the Controller region will grow larger because of all the mindless baton-passing it will have to do.

-=Cliff>
« Last Edit: March 26, 2012, 08:19:21 AM by puremvc » Logged
eliatlas
Jr. Member
**
Posts: 19


View Profile Email
« Reply #2 on: March 29, 2012, 12:02:44 PM »

Thanks Cliff!
Logged
Pages: [1]
Print
Jump to: