http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 2026601. Those principles you speak of as jargon are the core concepts of what patterns are about. I feel the reverse of your statement: understanding those concepts should come FIRST before even attempting to understand a pattern. I think you have the cart before the horse. To me the average developer should be trained similiar to how electricians are - they study under master electricians and learn the trade. These concepts such as #1 would be taught first. I think the point Ayende is making is that you can't call Webforms MVC because the whole lifecycle in webforms starts in the view. If sonic was MVC we'd see the controller starting the process, not the view creating the controller. Now, that being said: Webforms is called PageController ( http://msdn2.microsoft.com/en-us/library/ms978764.aspx ) the approach Ayende is making is called FrontController ( http://msdn2.microsoft.com/en-us/library/ms978723.aspx ) my 2 cents - just makes for more controversy. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment14http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment14Thu, 02 Aug 2007 19:39:53 GMTThat screencast is what prompted me to write: http://blog.bits-in-motion.com/2007/07/roll-your-own-mv-something.html I can say I've also heard sentiments similar to Harry's above in many contexts. These kinds of MVC perversions don't help. However... it's been my observation that architecture patterns are much more likely to be embraced when: 1. They can explained in a few sentences without resorting to jargon like separation of concerns, single responsibility principle, decoupling, unit testing, and SmallTalk. ;-) 2. The average developer has a multitude of examples to learn from. 3. In addition to being highly recommended, the architecture is perceived as "the right way" or "the natural way" to use a given platform. This essentially means getting first mover advantage and uniform acceptance when a new platform is released. Consequently most of the ability to dictate these things is in the hands of the platform vendor. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment13http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment13Wed, 01 Aug 2007 19:54:41 GMT@Ayende: The difference (RE the webcast) between Product.FetchAll() and ProductController.List() (there is no FindAll - but I know the point you're making) is that one is your model (Product), the other is a "controller" (or broker) that has nothing to do with the model - it just loads it. To some, this distinction is very important. My goal here is to allow people an alternative to piling model-logic into their code-behind (if they want it). In our structure, you can overload (or override) the List() and Get() routine to implement your own logic - this is our goal. My other goal is that *someday* there will be a true MVC pattern that can be implemented within the ASP runtime. When there is, I'm want the leap from data-broker to true contoller to be a small one. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment12http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment12Wed, 01 Aug 2007 18:30:16 GMTJosh, Monorail doesn't require ActiveRecord. You could use LINQ, NHibernate, homegrown 'x', etc... Glad to see the post. Could it called a MVP ? http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment11http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment11Wed, 01 Aug 2007 14:14:48 GMTOren, """From my POV, the controller is not a mediator but a coordinator, it is the driver for the specified use case""" the controller can be driver for a use case, if you can implement the use case with this controller alone. As soon as you need more than one controller for a use case (I usually have to implement workflows taking more than half a dozen pages in Visio) you cannot leave that to the indivual controllers. """Using your approach, how would you decide if you _should_ display an edit link? In the presentation layer?""" Beware! I have a simple workflow engine implemented that instructs controllers about possible continuations. The controller asks the engine about how to continue within a given workflow instance and then acts accordingly. This includes redirecting to the next page or commanding the view to render links to possible continuation pages. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment10http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment10Wed, 01 Aug 2007 09:32:44 GMTRob, The problem is that I don't see a significant difference between Product.FindAll() and ProductController.FindAll() http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment9http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment9Wed, 01 Aug 2007 09:01:55 GMTMarkus, The presentation logic decide how to show the link, the controller should decide whatever it should be visible. From my POV, the controller is not a mediator but a coordinator, it is the driver for the specified use case. Using your approach, how would you decide if you _should_ display an edit link? In the presentation layer? http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment8http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment8Wed, 01 Aug 2007 09:00:44 GMTOK just how great is MVC? Should I be pressing my company to switch all our development to it? I keep reading zillions of posts and articles and feel like I'm missing out, but I'm going to look like an idiot if I press for using something that turns out to be worse than ASP .NET. I work for a mid sized social networking site (million or so users) with 4 developers. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment7http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment7Wed, 01 Aug 2007 08:41:54 GMTFor anyone who's interested I think this post does a good sum up of MVC, presenter First, MVP patterns. http://www.continuousthinking.com/2007/3/4/recapping-ui-architectural-patterns I also saw a Model Conductor Controller (which I've never heard of until a couple of minutes ago) at http://rubyforge.org/projects/mcc/ which is explained as : Model Conductor Controller introduces the Presenter First design pattern to Rails web application development. MCC separates the responsibilities of your ActionController into a Presenter First MVP triplet – the model, conductor and controller. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment6http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment6Wed, 01 Aug 2007 08:32:17 GMTI'm a bit puzzled on this: """The test that I use for an MVC controller is very simple: "who decide whatever to show the Edit link on the table?" If the decision is made on the code behind, than this is not an MVC. If the decision is made on the controller, than we have proper separation of concerns. And when I am talking about a decision, it can be as simple as setting a flag per record, or the like.""" Generally, I agree with you, that fetching data is not sufficient for a conmtroller, but I want to take a broader approach. To me, a controller is a *mediator* for both parts of business logic: The business model and the workflow. The latter is often forgotten by model-focused programmers/architects/designers/whatevers, which leads to designs like the one you're complaining at. The problem is that the customers don't care much for the model, they want their workflows and processes implemented instead. Unfortunately, these tend to be buried either within the presentation logic or in the individual controllers when there is no explicit workflow logic behind the application, which makes maintainence of business processes very hard. Therefore the controller must not decide whether to display a edit link, it should instead fetch that info from a workflow/pageflow engine and pass it to the presentation logic which decides how to display the edit link. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment5http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment5Wed, 01 Aug 2007 07:51:55 GMTI was wondering if you were gonna light me up on this :). I'm pretty sure I mentioned about 5 times this wasn't "true MVC" and is more like a DataBroker model. I totally agree with you Oren in this case. That said, ActiveRecord can be a disastrous thing using WebForms because it's too damn tempting to load your controls from your model. I've been trying my hardest to abstract this stuff out a little better - thus the controllers. And who knows what could come of it, but I'm glad you got a post out of it :p http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment4http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment4Wed, 01 Aug 2007 07:48:34 GMThopefully you got some sleep between this and the previous post... I tend to agree and I do think Rob was talking about webform limitations. I'm actually thinking of playing with a monorail site using windsor, but subsonic for the controllers & models. Why? because I'm not really happy with the codegen I wrote to create the ActiveRecord classes from my db.. and I don't like to "put all my eggs in one basket". [It's a colloquialism where I'm from meaning not to bet everything at once or on the same thing.] http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment3http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment3Wed, 01 Aug 2007 07:08:26 GMTYes, but he still has the whole aspx / code behind stuff, no? Never got to see that one, but keeping that around would give some serious technical challenges for the framework. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment2http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment2Wed, 01 Aug 2007 06:04:16 GMT> true MVC is not possible with WebForms Scott Guthrie's non-WebForms MVC framework is likely one of the strongest possible agreements. http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment1http://ayende.com/2672/soniccast-3-it-is-not-mvc#comment1Wed, 01 Aug 2007 04:41:32 GMT