Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".
Related
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.
After doing some reading on the Model View Controller pattern it seems that the pattern is implemented quite differently in web frameworks vs desktop frameworks. With web based MVC frameworks the view and model never communicate directly. They can only communicate with the controller. But in desktop implementations, it seems that the view and model can communicate directly which doesn't make sense to me. That would seem to defeat the purpose of MVC of having separate, clean, isolated layers. Plus, what does the controller do if the view and model communicate directly?
Here is a diagram from Wikipedia illustrating MVC.
Model-View-Controller
It's a funny thing that I wrote recently an article on my blog about the different implementation of the MVC concept in web frameworks.
You can read it here.
also there is Presentation-abstraction-control
I found this article that seems to best explain the issue. http://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-mvc.html
It appears that there are really two architectures going by the same name: MVC and Model2.
Asp.net MVC 3 preview 1 was released at the end of last month. Are there any new features you are excited about or any features you would like to see before it is fully released?
Full support for Controllers with Generic Parameters
public GenericController<SomeType> : Controller
Generic controllers are quite possibly the greatest MVC timesaver if your doing a lot or business CRUD. There are so many similarities between the Add methods of almost every MVC project that it makes sense to abstract these operations out in a Controller that fits all scenarios.
Right now its a little hacky to create a generic controller. The MVC engine always gets the name wrong (GenericCo vs. Generic) and without full support plugin and libraries that interact with controllers just fall over when they encounter a generic one.
Make Dropdowns easier to work with
As a professional MVC tag watcher I've noticed that working with dropdowns is one of the most repeated questions on SO. The amount of Dropdown questions is a strong indication that something should be done to make it easier or less ... complex?
make checkbox list easy to work with
add T4MVC to the official release
add official helpers for OData
support one javascript library either MS Ajax or jQuery(preferably)
I wish they can add something to help developer to migrate their previous ASP.NET WebForms application.
I've recently discovered that MVC is supposed to have two different flavors, model one and model two. I'm supposed to give a presentation on MVC1 and I was instructed that "it's not the web based version, that is refered to as MVC2". As the presentations are about design patterns in general, I doubt that this separation is related to Java (I found some info on Sun's site, but it seemed far off) or ASP.
I have a pretty good understanding of what MVC is and I've used several (web) frameworks that enforce it, but this terminology is new to me. How is the web-based version different from other MVC (I'm guessing GUI) implementations? Does it have something to do with the stateless nature of HTTP?
Thanks,
Alex
It appears that MVC1 (model1) did not have a strong break between the controller and the view where as in MVC2(model2), these concerns were separated.
See if this gives you any more insight: MVC1 and MVC2 discussion
More InformationJust a little more
I Think this is the main difference between MVC1 andMVC2:
The hallmark of the MVC2 approach is the separation of Controller code
from content. (Implementations of presentation frameworks such as
Struts, adhere to the MVC2 approach). But for MVC1 did not have a
strong break between the controller and the view.
Model 1 Architecture: - Here JSP page will be responsible for all tasks and will be the target of all requests. The tasks may include authentication, data access, data manipulation etc. The architecture is suitable for simple applications.
Disadvantages: – Since the entire business logic is embedded in JSP chunks of java code had to be added to the JSP page.
For a web designer, the work will be difficult as they mite face problems with business logic.
The code is not reusable.
Model 2 Architecture : – The servlet act as the controller of the application and will be target of every request. They analyze the request and collect data required to generate response to JavaBeans object that act as model of the application. The JSP page forms the view of the application.
Advantages: – Reusability
Ease of maintenance.
I just started a new GWT project for a client and I'm interested in hearing people's experience with various GWT MVC architectures. On a recent project, I used both GXT MVC, as well as a custom messaging solution (based on Appcelerator's MQ). GXT MVC worked OK, but it seemed like overkill for GWT and was hard to make work with browser history. I've heard of PureMVC and GWTiger, but never used them. Our custom MQ solution worked pretty well, but made it difficult to test components with JUnit.
In addition, I've heard that Google Wave (a GWT application) is written using a Model-View-Presenter pattern. A sample MVP application was recently published, but looking at the code, it doesn't seem that intuitive.
If you were building a new GWT application, which architecture would you use? What are the pros and cons of your choice?
Thanks,
Matt
It's worth noting that google has finally written out a tutorial for designing using the mvp architecture. It clarifies a lot of the elements from the google i/o talk listed above. Take a looK: https://developers.google.com/web-toolkit/articles/mvp-architecture
I am glad this question has been asked, because GWT desperatley needs a rails-like way of structuring an application. A simple approach based on best practices that will work for 90 % of all use-cases and enables super easy testability.
In the past years I have been using my own implementation of MVP with a very passive view that enslaves itself to whatever the Presenter tells him to do.
My solution consisted of the following:
an interface per widget defining the methods to control the visual appearance
an implementing class that can be a Composite or use an external widget library
a central Presenter for a screen that hosts N views that are made up of M widgets
a central model per screen that holds the data associated with the current visual appearance
generic listener classes like "SourcesAddEvents[CustomerDTO]" (the editor does not like the real symbols for java generics here, so I used thoe brackets), because otherwise you will have lots of the same interfaces who just differ by the type
The Views get a reference to the presenter as their constructor parameter, so they can initialize their events with the presenter. The presenter will handles those events and notify other widgets/views and or call gwt-rpc that on success puts its result into the model. The model has a typical "Property[List[String]] names = ...." property change listener mechanism that is registered with the presenter so that the update of a model by an gwt-rpc request goes to all views/widgets that are interested.
With this appraoch I have gotten very easy testability with EasyMock for my AsynInterfaces. I also got the ability to easily exchange the implementation of a view/widget, because all I had to rewrite was the code that notified the presenter of some event - regardless of the underlying widget (Button, Links, etc).
Problems with my approach:
My current implementation makes it hard to synchronize data-values between the central models of different screens. Say you have a screen that displays a set of categories and another screen that lets you add/edit those items. Currently it is very hard to propagate those change events across the boundaries of the screens, because the values are cached in those models and it is hard to find our whether some things are dirty (would have been easy in a traditional web1.0-html-dumb-terminal kind of scenario with serverside declarative caching).
The constructor parameters of the views enable super-easy testing, but without a solid Dependency-Injection framework, one will have some UGLY factory/setup code inside "onModuleLoad()". At the time I started this, I was not aware of Google GIN, so when I refactor my app, I will use that to get rid of this boilerplate. An interesting example here is the "HigherLower" game inside the GIN-Trunk.
I did not get History right the first time, so it is hard to navigate from one part of my app to another. My approach is not aware of History, which is a serious downturn.
My Solutions to those problems:
Use GIN to remove the setup boilerplate that is hard to maintain
While moving from Gwt-Ext to GXT, use its MVC framework as an EventBus to attach/detach modular screens, to avoid the caching/synchronization issues
Think of some kind of "Place"-Abstraction like Ray Ryan described in his talk at I/O 09, which bridges the Event-Gap between GXT-MVC and GWTs-Hitory approach
Use MVP for widgets to isolate data access
Summary:
I dont think one can use a single "MVP" approach for an entire app. One definetly needs history for app-navigation, a eventbus like GXT-MVC to attach/detach screens, and MVP to enable easy testing of data access for widgets.
I therefore propose a layered approach that combines these three elements, since I believe that the "one-event-mvp-system"-solution wont work. Navigation/Screen-Attaching/Data-Access are three separate concerns and I will refactor my app (move to GXT) in the following months to utilize all three event-frameworks for each concerns separately (best tool for the job). All three elements need not be aware of each other. I do know that my solution only applies for GXT-projects.
When writing big GWT apps, I feel like I have to reinvent something like Spring-MVC on the client, which really sucks, because it takes a lot of time and brain-power to spit out something elegant as Spring MVC. GWT needs an app framework much more than those tiny little JS-optimizations that the compiler-guys work so hard on.
Here is a recent Google IO presentation on architecting your GWT application.
Enjoy.
-JP
If you're interested in using the MVP architecture, you might want to take a look at GWTP: http://code.google.com/p/gwt-platform/ . It's an open source MVP framework I'm working on, that supports many nice features of GWT, including code splitting and history management, with a simple annotation-based API. It is quite recent, but is already being used in a number of projects.
You should have a look at GWT Portlets. We developed the GWT Portlets Framework while working on a large HR Portal application and it is now free and open source. From the GWT Portlets website (hosted on Google code):
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
Every Portlet knows how to externalize its state into a serializable PortletFactory subclass (momento / DTO / factory pattern) making important functionality possible:
CRUD operations are handled by a single GWT RPC for all Portlets
The layout of Portlets on a "page" can be represented as a tree of WidgetFactory's (an interface implemented by PortletFactory)
Trees of WidgetFactory's can be serialized and marshalled to/from XML on the server, to store GUI layouts (or "pages") in XML page files
Other important features of the framework are listed below:
Pages can be edited in the browser at runtime (by developers and/or users) using the framework layout editor
Portlets are positioned absolutely so can use scrolling regions
Portlets are configurable, indicate when they are busy loading for automatic "loading spinner" display and can be maximized
Themed widgets including a styled dialog box, a CSS styled button replacement, small toolbuttons and a HTML template driven menu
GWT Portlets is implemented in Java code and does not wrap any external Javascript libraries. It does not impose any server side framework (e.g. Spring or J2EE) but is designed to work well in conjunction with such frameworks.