Let's look at what is meant by the term "business logic" ---> this is what implementspart of a solution for a problem statement. If we were talking 4-tier model, then we would say business logic and engineering logic; it is the implementation in language of the solution/problem space, and just a further decomposition --- still implementation logic, still about the solution.
With me so far? Now - what is presentation? It is how something is shown to the user. Does that require logic? Yes, it certainly can (consider javascript, etc.). What differentiates the logic of presentation form the logic of business? The concern, the type of processing. Is there some point at the boundary between these two where it might be fuzzy? Yes. How do you resolve that? You just make a choice, and do it however you choose. You'll probably do it differntly than I would. In the details, there's rarely a "right" or "wrong" - there's a better for this, or better for that. Back to this question about where do you define forms. What is a form? Is it strictly a presentation statement? Or is it a statement of required interaction with the user? Look: Business logic: "we need name, address, phone to take an order" Engineering logic" "we need input from user to collect name, address, phone" Presentation logic: "we want Name to be above address, address above phone - all on one form." Business logic: "the customer may save his information with us, but that is not required for an order" Engineering logic: "persist name, address, and phone if requested (e.g. offer request to save)" Presentation: "Checkbox for "save my info"" Now - where do you define form? It's a design decision - YOU decide. But some things are rather clear: validation logic probably should not be part of the presentation (although there may be valid reasons for this in your application) Defining color of form probably does not belong in the controller (better left somewhere else). Does it make sense to separate basic definition of an HTML form from the controller? That depends - are you going to allow input through PDF forms? csv? Then maybe it makes sense to separate this. If you're a web-input only application, then maybe not. By now you get the idea: some questions you can ask over and over, and get guidelines, and reasons behind them (e.g. color of form), but _most_ of these details are design decisions. Part of these are made or encouraged a certain way by the design decisions in the framework you choose to use; part of these will always be up to you, the software and web designer - what makes sense for one application will better be done another way; many things won't matter all that much... until you use them long enough, and then you will change your mind (e.g. refactor). mvc is just another way to say you've split your application into a data layer, a business layer, and a presentation layer - it's a separation of concerns; it serves to reduce design coupling. The goal is a maintainable and extensible app. The devil is in the details. Questions of "truly MVC" are like "truly agile" or "truly capitalist / market economy" or "truly social" --- as long as you don't loose the reasons behind these, why these abstractions (shortcuts to concepts) came to be in the first place, you're ok (otherwise you get into trouble): maintainable, extensible; frequent feedback; efficient, self-regulating allocation of resources in society; social responsibility to people in your community. :-) - Yarko On Tue, Mar 24, 2009 at 1:37 AM, Joseph Jude <[email protected]> wrote: > > All, > Just a question on the best practice - in terms of development & > continuous maintenance. web2py (like django) allows to define forms in > controller itself. And it allows having 'business logic' embedded in > views too. To bring out the application quickly, such mixing is fine. > But what about long term maintenance and also to call the application > truly MVC? What are your thoughts basis of your experience. > > Thank you for sharing your thoughts on this, > Joseph > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
