I know that most GWT based application now is being implemented using the MVP pattern, however I still want to know which MVC framework is the most mature and can be used for production-grade web application built with GWT.
Searching the web I can't seem to find a MVC framework anything comparable to Mvp4gwt and GwtPlatform in the MVP frameworks, in terms of user base and activities in the code.
If you must shoot yourself in the foot, these are the only two MVC frameworks for GWT that I've heard of:
http://code.google.com/p/gwt-mvc/
http://code.google.com/p/gwittir/
Neither of these have had a release in over two years. Probably due to lack of community interest, and because MVP is better in every conceivable way. Using MVC with GWT is like installing square tires on a Ferrari.
You could use JetPad-Mappers, a minimalistic MVC framework developed at JetBrains and used in several (currently unreleased) products.
https://github.com/JetBrains/jetpad-mapper
Disclaimer, I am involved in development of this framework.
Related
For an upcoming project, I am looking into MVP as an option over MVC. I am highly familiar with and like MVC, and am merely trying to see if I will gain anything using MVP.
What I gather about MVP is that it uses the ASP.Net view engine/MVC# (which I don't particularly like) that uses the ViewState - adding a bunch of extra content to a rendered web page, and not built in routing functionality (can be written in separately into the Global.asax).
MVC/Razor on the other hand, renders very clean HTML.
Certain articles, such as this one seem to lean towards using MVP for multiple views, however in light of MVC3 with jQuery Mobile, there are some fantastic things that can be accomplished with this MVC.
How do these compare to what is currently available with MVP? What are some pros/cons or potential pitfalls of using MVP over MVC?
I am also considering using an existing MVP application to expedite development time.
I know you will cringe at the following, but looking for options:
While this app offers all the required features, if implementing this solution, how difficult is it to tie in additional MVC applications (I know that looks ugly)? If this was something that we had to consider (combining both), would it be best to wrap the application in MVC (routing) and have the MVP app contained inside?
The reason for this is a staggered feature update process, where the requirement is to implement a new feature (which is built using the MVC framework; the rest of the system is not). Future plans are to completely change the current framework to either MVC or MVP.
Thanks.
You seem to be confusing patterns with frameworks here.
Both MVC and MVP are design patterns, ASP.net MVC and MVC# on the other hand are frameworks that implement the MVC/MVP design patterns.
There is a massive confusion and lots of conflicting information on the web about the difference between MVC and MVP patterns and infact Martin Fowler the guy who made MVP popular since "retired" the pattern in favour of 2 new ones. See here
Both patterns are there to aid separation of concerns that is for sure, but other than that there really isnt a lot of difference between them, the only thing I have found is that MVC has a controller per widget on the screen where as MVP is one per screen although even this rule is violated if you have a complex screen. I am still unsure and use the terms interchangeably myself.
The one thing I see over and over is that in MVP the view is responsible for creating the presenter, however this is not part of the original design. It appears to have arisen from the fact that older web frameworks such as asp.net webforms were page centric. You had no way of changing this and so it was the page (view) that created the presenter. Basically the framework is getting in the way of the pattern and so a hack was made to shoe horn it in. Unfortunately this seems to have become the defacto way of describing MVP.
Basically my wall of text above is trying to say that if you want to do MVC properly use a framework designed to do it, ASP.net MVC is a good choice, it is part of the MS stack, well supported (MVC# hasnt been updated since 2008) and if you are already happy with it the loss of productivity trying to learn something else isnt really worth it imo
I know there is already a lot of discussion here, but things change quickly and new frameworks are published.
I am looking for a robust HTML5 framework with which I can create both, Web AND Mobile applications if possible. I do want to create an application for the Web and Mobile (Android/iOS) and I do not want to use two or three different HTML frameworks.
On the server side there is Spring with Hibernate (Java EE application server). I know there is Titanium, Phonegap, GWT, Grails, jQuery, SpringMVC and much more. However I am not sure what to pick and if I could to Web AND Mobile with those. Actually I am not sure if it makes sense to look for one particular framework that can do both, but I assume from a learning perspective it might be right. I also know there is Adobe Flex which runs in a Flash Player on the Web and on Mobiles, but I do not want to use Flex (because of the Adobe announcement yesterday, I think Flex/Flash has not future on mobiles).
Ideally the framework should be well documented, robust and have a good community.
Thanks!
Maybe MoSync is a good choice for you in MoSync you can combine HTML5 with C/C++. So you get the best of two worlds, HTML5 and native.
I want to write a web site using ASP.NET MVC 3.0 and Microsoft technologies. I'm studying it now, and enjoying it.
The web site is experimental, and will be used by me and my son in house, but of course I will want to grow it and let other people use it. It will be in Hebrew.
What other technologies do I need to study? One I'm sure of is C# 4.0 (and LINQ). But I'm not sure about ASP.Net 4.0 - Do I also need to study it? How about Html 5? Javascript? Entity framework? Ajax?
Well here's my $0.02 worth of advice. I guess if your are going to expand this site at some point in the future you would have to add Enfity Framework 4 as well in terms of how you do your data access and JQuery since it comes out of the box with your MVC projects. Since you are developing it now you might as well add HTML5 to the list. With respect to ASP.NET 4 you might not need to if you're only doing this for your site. It's a pity that there aren't any mvc3 books our yet but you could either refer to blogs for newer material or if you don't mind use MVC2 books to help you along with u
I'm wondering just where a CMS - out of box like SiteFinity, Sitecore, SharePoint, DotNetNuke, etc. - fits with the MS MVC Framework (1 or 2). The MVC Framework presents a lot of benefits for developers and for overall SEO and SEM value, while most CMS platforms require a lot of the WebForms "stuff" that comes with ASP.NET. Thoughts? I'm trying to figure out if these two pieces fit well together for future projects, or if they are disparate concepts?
BTW: I realize that a custom CMS could work, however that can require an awful lot of extra time than just setting up an instance of an out of box CMS.
MVC is a pattern. There are CMS systems that are webforms-based, like DNN, and ones that are based on MVC, like Orchard. Either framework (Webforms or MVC) are equally capable of supporting a CMS. Your choice should be based primarily on the one that offers the features you want. If you expect to extend it with plugins, and you're already familiar with Webforms, go with the one you know unless you want to learn MVC.
My thoughts are you very limited in the tools/components available to you at present when you choose to go the MVC route. Although there are a few CMS components out there for MVC they lack maturity IMHO. I believe in a couple of years when MVC has more maturity you'll be able to achieve the speed and sophistication of application development that is close or on par with Webforms.
Right now though if you have a lean project budget, and you need sophisticated functionality (i.e. CMS); Webforms still remains hard to beat when you have those constraints.
What I want to create is a Silverlight app with a few tabs/modules that will all be separate DLLs.
I see PRISM has the Shell/Module concepts that seem directed towards doing UI and I find a nice demo (showing how to search digg/twitter).
But it sounds like MEF will be included in VS2010 so I would like to go with that option.
Can anyone somehow clearly explain the differences? (I am not a advanced programmer)
MEF and Prism serve two very distinct goals.
Prism is basically guidance for designing composite applications - where you have a shell and "regions" that are dynamically assigned, and integrated. It includes an IoC container (Unity) that it uses for it's injection.
MEF is a dependency injection framework - it's main goal is to "fill in" depedencies at runtime for an application. In this respect, it's filling the same goal as Unity does within Prism (and, in fact, you could pretty easily rework Prism to use MEF instead of Unity).
Prism fills a broader scope, in some respects, but is also really limited to GUI applications. MEF is just doing one thing (Dep. Injection), but geared to be more general purpose, for any type of application.
As for the lifetime of these products -there is no answer here, but this is kind of how they're being developed:
Prism was developed by the Patterns and Practices team. The goal isn't to necessarily make software, but to provide guidance. As such, they update (although somewhat infrequently) the Prism library and sample, but Prism isn't a core part of the framework shipped by Microsoft. It's really a third party library (even though MS funds a lot of it, most of the P&P people aren't MS FTE).
MEF, from the blog posts, sounds like it is planned to be integrated into the framework, and be used directly inside of MS projects. As such, it's getting heavy development, directly from Microsoft, and being used in their products.
I, personally, have read through the Prism documentation (and have the book), and have gone through the samples. It is very helpful to understand how to break apart an application, but it really is guidance more than a complete, usable framework. The samples are very good at doing what they're designed to do - educate an architect in how to design a composite application.
If your goal is to just keep a clean separation of concerns in a silverlight application, I'd focus more on learning MVVM than necessarily just using Prism.
If you want to use MEF, there are other good options. For example, the WPF Application Framework is an entire MVVM framework built on top of using MEF, and fairly nice.
Basically, MEF is a general-purpose extensibility framework:
If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.
whereas Prism is mostly for building GUIs:
The Composite Client Application Guidance is designed to help you more easily build modular Windows Presentation Foundation (WPF) and Silverlight client applications.
So MEF and Unity are basically the same...
Well, not exactly. MEF is more focused on extensions which aren't known at compile time, while IOC containers generally focus on dependencies which are known at compile time. The top answer to this question gives a good explanation of the differences.
Yes. Check these two posts for more:
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
http://blogs.msdn.com/dphill/archive/2009/12/09/prism-and-mef.aspx