There is one more concept that is worth some words (although I don't want to turn this into a blog about mvc): Design coupling is an interesting topic - perhaps the best discussion I've seen on it was in Nam Suh's book "Axiomatic Design" (although I don't recommend that as a general design book - I think it misses some important points).
Like "pure MVC" (or any of the other topics already mentioned) design coupling is the effect where, in order to change some part of a system, a dependent (coupled) part must also be modified. The worst of coupled design is that it results in a cascade of changes that in can (at very worst) be never ending, e.g. you cannot really make the desired change at all. A more functional version (!) is where to change some small aspect of a system, you must change many other parts of the system to accomplish your initial goal. So it would seem that decoupled design is "desireable", and while the general concept is true, there is a very important point: There is natural coupling in all problem spaces, and you or constrained to respect that natural coupling in your solution - it is, after all, a part of the definition of the problem space. (Of course, you don't want to amplify it, or introduce additional coupling - and certainly not any "unnatural" coupling - that is, coupling that is not dictated by the problem space). So it is with forms: they are naturally coupled items: you want layout of input items, but they represent data you need to interpret and save - they are naturally coupled. And this is why forms "seem" confusing when talking about MVC - but, really, they're not. They are as they are naturally - they must be so. The biggest "hurdle" is to see that, and accept it in the correct context. There are other areas that accidentally introduce coupling - I ran into such an instance in web2py (actually, in the csv library) recently. It's nasty when you spot the coupling, and (of course) it will at some point be removed (the unnatural coupling, that is...) </end blogging> Yarko On Tue, Mar 24, 2009 at 5:36 AM, AchipA <[email protected]> wrote: > > Yarko alredy explained this nicely, just one minor point to add - the > MVC paradigm was not created for web apps. In a web environment, MVC, > as a concept, cannot be strictly realized as a consequence of the http > server-browser decoupling. Hence it's not a question whether a web > solution is or isn't fully MVC decoupled, but rather which corner of > MVC will you cut to fit technical and real life limitations. And this > is where Yarko's argument comes in - it's about design choices, > starting from the choice of the framework itself down to the location > of form operations or helpers in your particular application. The > bottom line is, don't let a pattern determine your project, but rather > choose the best patterns based on your project's requirements. > > On Mar 24, 8:22 am, 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 -~----------~----~----~----~------~----~------~--~---
