Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
March 23, 2017, 03:06:46 PM
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: Distinction between business vs domain logic  (Read 13059 times)
eco_bach
Courseware Beta
Sr. Member
***
Posts: 81


View Profile
« on: July 14, 2009, 03:30:43 PM »

Can someone give a few examples of typical 'business' vs 'domain' logic?
Not quite clear on this distinction although I understand that best practice is to keep all domain logic in the model-proxies and business logic in the controller-commands.
« Last Edit: July 15, 2009, 12:09:23 PM by puremvc » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2860



View Profile WWW
« Reply #1 on: July 15, 2009, 12:08:30 PM »

From Implementation Idioms and Best Practices 1:

Quote
The first distinction to make about the logic in your application is that of Business Logic and Domain Logic.
Commands house the Business Logic of our application; the technical implementation of the use cases our application is expected to carry out against the Domain Model. This involves coordination of the Model and View states.


The Model maintains its integrity through the use of Proxies, which house Domain Logic, and expose an API for manipulation of Data Objects. They encapsulate all access to the data model whether it is in the client or the server, so that to the rest of the application all that is relevant is whether the data can be accessed synchronously or asynchronously.

The key thing to keep in mind here is that the Model classes (Proxies, VOs, Enums, and the like) may often be reused in more than one application; say, an AIR desktop client and a Flex web client that have different use cases but carry them out against the same Domain Model. Therefore, the Model tier classes should know nothing about the business needs of the application it is a part of 2 and should only be concerned with the data, how to get it, and how to make sure it's clean.

Keep in mind also that the responsibility of maintaining integrity can be spread across the Proxy and data objects (such as a VO or Enum). Using an Enum, for instance gives you a built in list of valid settings, which can fill a combo and restrict the user to the correct input 3. And any property on a VO can easily be turned into a set of accessors (implicit getter/setter pair) which can ensure that the data is set properly, provide defaults, derive settings, etc)4.

-=Cliff>

1 IIBP: http://puremvc.org/component/option,com_wrapper/Itemid,174/
2 This includes not referencing constants or classes defined in the Facade or the View and Controller 5 tiers. Consider writing your Model classes from the start in a separate library project, imported into the application. This will put up a physical barrier to code dependencies in the Model which will have no access to the application classes.
3 See an example of an Enum in the model package of the Employee Admin demo: http://puremvc.org/pages/demos/AS3/Demo_AS3_Flex_EmployeeAdmin/srcview/
4 See an example of a 'Smart VO' here: http://forums.puremvc.org/index.php?topic=1293.msg5973#msg5973
5 From the 'exceptions to every rule dept: While Commands are generally registered by the application's Facade and used to execute Business Logic for keeping the View in sync with the Model, it is possible to create Commands that are packaged separately with Model classes and that are registered by the Proxies themselves rather than by the application. Then the Proxies can send Notifications to these Commands, confident that they will be registered to the note names they know, and use them to offload Domain Logic tasks that would otherwise make for a cumbersome Proxy.
« Last Edit: July 15, 2009, 12:14:55 PM by puremvc » Logged
Pages: [1]
Print
Jump to: