On my MVC app, I am planning to create a generic method for Web Api's. This can be achieved either creating methods on Base Controller or methods in Utility helper class. Which is preferred way Base controller (or) Utility Class?
And also want to know on what scenario's Base Controller is useful.
ASP.NET MVC provides several alternatives to common problems (e.g. logging, exception handling, authorization) using filters or allowing your own implementation of a certain class. Usually a base controller is not the best approach since it is very likely the framework already handles the issue by other means.
Take a look at this answer for how to deal with common problems in ASP.NET MVC: https://stackoverflow.com/a/6119341/1942895
Related
File -> New Project for ASP.NET MVC projects used to generate controllers with virtual actions. I'm not sure if that stopped with MVC 2 or MVC 3, but is this no longer a best practice?
T4MVC Does make action methods virtual. If you are using it, it should make action methods virtual, no other way it can work
The current documentation for ASP.NET MVC 3 does not show virtual methods. I'm not really sure what making them virtual would gain you, as I've never subclassed controllers to override actions.
Generated code may be made virtual for various reasons. It's not good practice to make your own code virtual unless required by some tool. See Liskov Substitution Principle and Open/Closed Principle. I think some frameworks do this to facilitate creating proxies but I can't imagine any reason to make all of your methods virtual. To me it screams copy/paste or cargo cult programmer.
A discussion came up at work recently about why ASP.NET MVC doesn't use static methods for its controller methods. Whilst I was on the side of the fence against using static methods, the only two arguments I could think for non-static action methods were inheritence and the ability to mock (which inheritence gives you).
What was Microsoft's design choice for non-static actions/methods over static?
While I don't know minds of those that designed the ASP.NET MVC Framework here is the big one for me:
An instance controller is instantiated once per request, multiple requests can be happening simultaneously. If a controller is static then any state on the controller is shared across all requests simultaneously. You probably don't want that. Updating that shared state becomes a minefield of locking contention, possible deadlocks and very hard to track bugs if locking isn't implemented properly.
In short, a static controller would be a nightmare to work with.
You have for example controller "Home" and action "FillData",
and another controller "Student" and action "FillData".
Imagine what will happen if you make action "FillData" a static method, and could be called in any other controller easily.
It would be a big ISSUE.
I've made a simple website in ASP.NET MVC Framework with users, articles etc., and images to users profiles. There is a simple static class for image manipulation (resizing, cropping and saving images on hard drive), placed in "Helper" directory. I wonder what to do with the code to preserve MVC principles and make whole website more unit testing friendly.
Grettings
Make the helper class non-static, declare it as argument of you controller constructor and inject it with a controller factory that uses dependency injection.
In order to make your controller not dependent on your image manipulation helper, you'll need to have it talk to an interface, rather than a concrete class. So make an interface like IImageManipulator, and have your controller call methods on that interface rather than on your class. Your image manipulator class will need to implement this interface. You'll need to use a dependency injection technique to get the concrete implementation injected into your controller (there are several acceptable ways to do this).
Now your controller will depend on an interface and not a concrete implementation, allowing you to unit test your controller by mocking the IImageManipulator interface and injecting that mock into the controller.
I'm running into an issue with the Policy Injection Application Block from Enterprise Library in conjunction with ASP.NET MVC.
In my ControllerFactory, I'm creating the controller and then calling PolicyInjection.Wrap on the controller. This gives me back a Transparent Proxy to the controller which manages the call handler chain.
Finally, I cast the Transparent Proxy to an IController and return it.
This seems to work well, except that none of the call handlers I've defined for my controller are executing. (For example I have a Logging Handler configured, but nothing is being logged by PIAB.)
Is my final cast messing this up somehow? How does ControllerBase.Execute() call into my controller? It seems like my proxy should be utilized. Anyone using PIAB on ASP.NET controllers?
I am using PIAB to wrap ASP.NET MVC Controllers, and I'm doing so by calling
PolicyInjection.Wrap<IController>(instance)
which will wrap the IController methods. I'm also using policy injection to wrap the IActionInvoker that gets used as well, which allows for logging the action name.
I have not had success wrapping controllers using the MarshalByRefObject wrapping, but the interface wrapping works like a charm.
If you want additional information, you could create an interface that has all the methods from IController, IActionFilter, IAuthorizationFilter, IExceptionFilter and IResultFilter and then have your controllers implement that interface. Then you could wrap your controllers as that interface and get more calls going through policy injection.
I hope that helps. If you have more specific issues please post.
Seems at least one person uses it :) - ASP.NET MVC Validation using Policy Injection Application Block in Enterprise Library (this is first result BTW)
I'm trying to learn the new ASP .NET MVC framework and would like to know the best practice for using UserControls.
I understand that you can render UserControl's as a partial and pass data to them from a controller. Ideally I would think that it makes sense not to have a code behind file as this creates a temptation to break the MVC rules.
I'll give an example where I don't understand how UserControls fit into the pattern.
I have a UserControl that shows the
latest tags (much like on
StackOverflow). Unlike StackOverflow I
want to display this UserControl on
all of my pages. If I have a
controller say QuestionController
which is meant to handle actions from
some question views e.g. view and
detail, does this mean I have to fetch
the data in the QuestionController and
then pass it to the UserControl?
If I create another controller say
SearchController then I would have to
replicate the same functionality to
get the latest tags to pass to a
partial again. Doesn't this mean that
the 2 different controllers are doing
extra things that they weren't
originally intended to do?
If your UserControl appears on every page, then one way to address this would be to use a base controller from which all of your controllers derive and generate the ViewData for the UserControl by overriding the OnActionExecuting method and putting the logic there. If your UserControl is less pervasive, but still frequently used throughout the site, you could extend ActionFilterAttribute and have your filter generate the needed data. This attribute could be used to decorate the controllers or actions that generate views that use the UserControl.
I'm assuming in all of this that the data for the UserControl is independent of the action being invoked. If there is a dependency, it's probably best to push the logic into a class (or classes, perhaps using Strategy) and make the generation of the data explicit in each action or controller (via overriding OnActionExecuting).
Alternatively, with ASP.NET MVC 2 you can now use RenderAction to call a completely new controller action which can fetch the data. This makes your code much more modular and it is more clear where the data is coming from.
You can also consider putting your model classes in an hierarchy. The upper class (or one of the upper classes) will contain data necessary for your pervasive user controls. Then you can load these commonly used data in a base controller class.