Context: Using Unity in (C#) ASP.NET MVC3 framework.
Mark Seemann suggests "In ASP.NET MVC applications it’s global.asax and a custom IControllerFactory" - (Source).
I have read other credible sources suggest to use the UnityDependencyResolver (MSDN, Adam Tuliper, Darin Dimitrov).
Darin also suggests that the two are mutually exclusive.
Which way is best practice?
MVC 3 introduced a new way to handle Dependency Injection called IDependencyResolver. In MVC prior to MVC 3, you would use IControllerFactory. In MVC 3 you would use UnityDependencyResolver.
UnityDependencyResolver is an implementation of IDependencyResovler interface. This allows Unity to be integrated into .net without having to write a custom IControllerFactory.
They are mutually exclusive, in that if you use one you would not use the other.
Related
I'm creating a web app using ASP.NET MVC 3 and Entity Framework 4.1 code-first. I'm designing the project via Repository Design Pattern. I know how to implement RDP and Generic RDP. But my question is that using StructureMap is a good idea on this case? Thanks to any idea and help.
Well yes, but structuremap is more related, imo, to the DI approach you will use than the Domain specific approach you will implement.
I personally use AutoFac, but Structuremap is a also very good, you may want to consider also Ninject. All of them are really powerful and have a nice syntax to work with imo.
What's the best way to structure the base functionality of an ASP.NET MVC 3 solution so it can be reused in subsequent solutions? For example, I'm going to develop a basic skeleton MVC app with user registration using email verification, enhanced users/right/roles, blogging with comments, and a forum. I understand maintaining the business logic in class libraries but how about the controllers and views? Do I basically have to just copy and paste my base solution to create each of my new solutions?
Creating a Custom ASP.NET MVC Project Template
templify
I am going to start new MVC 3.0 .NET 4.0 application.
I want to implement each component for my web site once and simply reuse it then for another web sites i going to build.
Currently i am looking the best practice i can use to achieve my goal.
I did some research and found that I may get a lot of advantages using MEF.
I found interesting MEF MVC solution called plugable MVC http://www.thegecko.org/index.php/2010/06/pluggable-mvc-2-0-using-mef-and-strongly-typed-views.
Is it really worth to use such kind of approach(Plugabble MVC) of building MVC apps?
Advantages disadvantages of pluggable MVC?
May be somebody may suggest something else?
What specific problem are you trying to solve? MVC is a very extensible and pluggable framework as it is. I would say that for a simple site MEF is not necessary. Please provide more information on the issues you are running into with the stock MVC framework.
MVVM is a Microsoft design pattern that existed before ASP.Net MVC. Can anyone through light on differences between MVVM and the new MVC pattern?.
Can anyone throw light on differences between MVVM and the new MVC pattern?.
Yes: When using ASP.NET MVC the MVC pattern uses the controller to render the model directly into the view. This is perfectly acceptable for trivial projects with a small number of objects. Where this can become a problem is that the concerns of the UI layer can bleed through to the underlying (domain) model.
When using MVVM then you are adding an abstraction between the Model and the View, which is of course the ViewModel. This allows the author to project into the view an object that is most readily consumed by the view. The ViewModel can contain things which would be out of place in the (domain) Model. The cost associated here is that you need to have mapping logic which transposes the data from the model to the View Model. Tools like AutoMapper can assist with this chore.
A simple example of this might be the Model doesn't require certain fields as required, but a particular View does. Rather than baking this logic into the user interface, if it is attached to the ViewModel, then other UI's can consume the same VM without having to duplicate logic that was baked into the first user interface.
MVC and MVVM are actually quite different. There seems to be a fair bit of misunderstanding of MVVM when talked about with ASP MVC. The practice of making 'View Models' in MVC, which are specific classes to feed views, while good practice is not true to the spirit of MVVM, and in fact is just a cleaner version of MVC.
MVVM is more suited to the desktop using WPF or similar, or purely in the browser using a JavaScript framework such as knockout.js. The pattern is quite different to MVC and involves views being 'subscribed' to the model.
I would venture to suggest that MVVM is Microsoft's design pattern and ASP.NET MVC, which is farily recent, is a specific implementation by Microsoft (that doesn't necessarily adhere to either MVC or MVVM but is similar). And as suggested by Reed, MVC has been around since the 70's.
Both MVC & MVVM are architectural patterns. MVC has its roots way back to Smalltalk. ASP.NET MVC is Microsoft's implementation of the MVC pattern using ASP.NET framework.
Both the patterns deal with separation of concerns. MVC is more to do with the interaction of various commonly used layers in an application like Model (data layer), View (presentation layer) and Controller (business logic layer).
With advanced databinding capabilities of WPF and Silverlight, MVVM was more suited and publicised as the next big thing. Martin Fowler generalized these patterns as presentation patterns in his Enterprise Application Architecture book.
One advantage I see in using a ViewModel is that it allows you to test the application code better using unit tests. Because of this reason I find MVVM or at least the ViewModel bit of it being used quite often in ASP.NET MVC applications as well.
Two of the biggest advantages of MVC over webforms were non-existent viewstate and URL routing. VS2010 and .NET 4.0 incorporates built-in URL routing for Webforms as well as better control for viewstate.
I advocate use of MVC for extranet sites due to the MVC design pattern and its general lightweight nature but in light of this new announcement has Webforms closed the gap? Why would you still pick MVC over Webforms?
Thanks
You're forgetting about 2 main advantages of MVC: better control over generated HTML and better support for test-driven development.
I'd say that normally implementing a site using ASP.NET WebForms would require less effort that implementing exactly the same with MVC.
MVC gives you more control, but it also requires more expertise and effort.