My pleasure (really, literally! ;-) On Tue, Mar 24, 2009 at 3:36 AM, Joseph Jude <[email protected]> wrote:
> > Yarko, > Thank you for the detailed explanation. :-) > > Joseph > > On Mar 24, 12:22 pm, Yarko Tymciurak <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
