Yarko, Thank you for the detailed explanation. :-) Joseph
On Mar 24, 12:22 pm, Yarko Tymciurak <yark...@gmail.com> 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 <ceph...@gmail.com> 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 web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
