You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2001/08/28 12:50:23 UTC

Re: Yes, but what is business logic? (was: Business Logic in View a bad thing (was floating point types))

On 8/28/01 4:06 AM, "Lloyd Llewellyn" <su...@twilight-systems.com>
wrote:

> 
>> Think about it: "if the user's score is this..." this is BUSINESS LOGIC. You
>> should never have this kind of code in your view.
> 
> This is not necessarily business logic - where the boundary lies between
> business logic and the view depends on the application design.  The
> requirements of an application's view may simply be "display the results
> to the user".  The business logic doesn't care how that is done as long
> as the results are clear.
> 
> If you get too pedantic about separation of view and content, you end up
> with a situation where deciding whether a pixel on a monitor should be
> on or off becomes a "business logic" decision.  Not all logic is
> business logic.  Some logic is required to render the view.

I agree in principle, that it's hard for 'us' to say what is business logic
and what isn't, especially when Velocity isn't a niche tool, but more
general purpose.
 
> Rather than focusing on the example presented in the previous message, I
> believe the question is: Is the float data type so complex and
> incomprehensible to the designer that all manipulations of that data
> type should be the exclusive domain of the developer?  I submit that it
> is not.  
> 
> A float is no more complex than, say, a string.  It's a basic data type
> - there is no reason why designers shouldn't be able to inspect and use
> floats.  There is no logic to a float - it is simply a data type. Please
> tell me where logic of any kind - much less the business logic that
> defines an application - comes into play here.
> 
> I believe there is no legitimate connection between the prohibition on
> floats and the separation of view and business logic.  If anything,
> forcing a designer to have knowledge of utility objects placed in the
> context in order to deal with a fundametal data type like a float
> threatens this view/logic separation more.

I think it is a bit extreme to deny any connection.  I think that there is a
connection - what that connection is remains the question. This still comes
down to how substantial we believe the connection to be.  One of our driving
philosophies has always been to keep it simple, clean, and support the MVC
contract.  I think that recognizing that has served us very well and there
are quite a few examples of where we do diverge from that path for
convenience, for example the quiet reference, $!.

 
geir