Yep, something like that... On Wed, Jul 21, 2010 at 10:35 AM, Bill Barry <[email protected]> wrote: > hammett wrote: >> >> - Competitive landscape >> MS MVC: I can't comment. Anyone cares to share the pros/cons? >> Strengthens/weaknesses? >> > > In the issue of Monorail vs MVC in a pro-mr viewpoint (admittedly I use MVC > in my projects, but it is abstracted enough that I can probably swap it over > in a few hours time; using Spark for my view engine): > +++ mr is tightly focused on providing an mvc structure (MVC is built on top > of ASP.NET and there is abstraction leakage there that you should ignore > while using it) > + mr has the ability to be updated outside of a .NET Framework release cycle > - MVC pretty much has all the functionality of mr covered > --- MVC is free and already part of the stack you are already using > > I am not aware of any functionality that is available in Monorail which > isn't either also available in MVC or easily added with some code you can > copy/paste from online somewhere (and generally available already in the > MvcContrib project; MVC+Contrib is really what I would consider mr's equal). > I do know there are things you can do in MVC that you can't (though you > wouldn't want to) in mr (views with code behinds which can contain postback > events (yes, postbacks can be done in MVC: very very ugly stuff) and > "service methods" (ajax server callbacks in the code behinds to provide data > for controls)) > > As far as I am concerned, Monorail has accomplished any primary goal it has > ever had: It caught the attention of MS and got them to consider an MVC > arch. Millions of people are now in a better position than they were because > of this. > >> >> - Goals (not in any particular order) >> Community ecosystem: contributions are encouraged to be packaged and >> made available side-by-side, similar to facilities.. >> Acceptable Performance, fair trade-off contrasted to other benefits >> Lightweight: Minimal extensible core with predictable behavior. >> Composable: The framework grows or shrink in functionality based on >> extensions made available to it. Light-up should be automatic, or with >> minimal intervention >> > > Is there any MEF-like magic worth considering here? > > I am thinking of a scenario where someone does: > > 1. download: > monorail.dll > monorail.auth.sha2.dll (comes with several view templates in various > template languages to place in your views dir and modify) > monorail.mysuperduperforum.dll (someone's implementation of a forum, comes > with a half dozen views) > monorail.fooblog.dll (another person's implementation of a blog, comes with > a couple of views) > monorail.store.dll (implementation of a simple ecommerce site; a couple more > views) > monorail.adsense.dll (implementation of google adsense; more views) > > 2. tweak the look and feel of the views a tiny bit > 3. add headers, footers and a menu system > 4. create an empty database and wire it up via web.config (or some app > startup code) > 5. fire up the site. > > Suddenly without writing hardly any code a person has a personal website > with a blog, small store, forum and adsense, complete with an administrative > system. Did I mention that all of the components are very well covered by > unit tests and highly regarded by the community. When the developer needs to > actually write some new custom component there are dozens of tutorials to > help him on his way. > > MonoRail in its barest form should be the MVC system. But it should be very > easy to write components that can lock in with MonoRail, Windsor, NHibernate > (or AR), Migrator.NET (or some other solution) and each other (no more above > writing a regular MonoRail app than adding a single class that is exported > by MEF and implements some interface). This is how big the pit of success > needs to be. It is not enough that I fall into my pit and you do yours with > our two separate applications. I should fall into mine, and you into yours > and then we should be able to trade codebases and recognize the code that we > would have written ourselves. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" 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/castle-project-devel?hl=en. > >
-- Cheers, hammett http://hammett.castleproject.org/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
