I'm still a bit of a noob when it comes to working with MVC projects in visual studio but I often find it necessary to navigate from a specific view into the details for the business logic used by that view, usually one or more controllers. So far I have only found these approaches.
Search for a controller using the "controller" naming convention. If I'm looking at a view called "UserOrder" it is likely that the controller will be named "UserOrderController".
Search for the name of the model class in the hope that it was instantiated in the controller class.
My question is whether there is a better way to identify which controller is using a particular view?
Related
I'm familiar with the various bits of functionality of the MVC plugin to create things. For example you can create a controller, write an Action method on it, then use the "create view" function in the context menu to create a view for it.
The question is, which is it recommended to do first?
I'm thinking I might start myself a methodology like this:
Plan out what the UI etc will look like and how it will work.
Write unit tests for the controller actions I think I might need.
Create Controller (maybe with default CRUD actions if it's to be that kind of controller).
Create ViewModel class for each controller action.
Create a strongly-typed view for each ViewModel.
Start building the view, working back through the ViewModel to the Controller as the View is built up.
What do you think of this approach, and what do you do?
Sounds like you're on the right track. Controllers are the most easily tested component of the three. Going controller-first will make it easier to follow Test-Driven Development practices.
I've not been perfectly happy with the default view templates, but every MVC guru will point you to T4 templates, which let you roll your own. They, like the out-of-the-box view templates, will be more effective with existing view models and controllers.
I'd be tempted to define the ViewModel first, the VM(s) can consist of all or a subset of the entities required for the various Views. How you segregate your VMs would depend on your app and how you are breaking up logical units within that.
Once I had the VM(s) in a basic form I would move to Model necessary for my chosen data store (unless I had an existing data store in which case I'd have started with the Model). Then onto the controllers. You can then apply TDD with a mocked data source to verify that the VM objects returned by the controller actions match expectations. Lastly, I'd generate basic strongly typed Views (based on the ViewModel objects) for each controller action that actually resulted in UI.
Then it's play time with Jquery and CSS to make it look presentable.
i have several controllers which will all be using common functionality. So i have separated that functionality into a separate controller.
the shared controller needs a parameter specific to which controller it is being used from, and needs to return views based on id ints passed to it.
So, one idea is to create an instance of SharedController(int callingControllerId) in the constructor of each of the controllers that will be using it. Then, within the action methods of each controller, call the action methods of the shared controller, passing appropriate ids, and returning views from SharedController to the calling controller, which would return the view to be rendered.
Does this sound right? Should controllers be creating other controllers in MVC?
Thanks!
Absolutely not although having your controller inherit from a shared, base controller is pretty common.
public KittyController : MySharedBaseController
{
}
Like Greg Roberts points out that although having a ControllerBase is common it is not always the best place to store shared functionality. MVC has a lot of extensibility points and picking a narrow place to wedge in your code is a lot better than smushing tons of things into a base controller.
I would agree that a base controller is pretty common, but I'm not sure it's the right solution for what you are describing.
Without knowing what is exactly shared it's a bit hard to figure out, but the whole bit of your base controller knowing specifics about the controllers that are inheriting from it smells a bit.
Here are a couple things to consider.
Composition is almost always better than inheritance. Great article on this
Base controller should have common methods/properties, for example mine have some properties of getting the current user and a generic method for calling external services, but not specific things from inheriting controllers. Rule of thumb, if it's not needed by more than 1 controller, than probably not good in base implementation.
It's possible that some of the new MVC 2 features might solve what you are doing. Look at render action.
As with anything in software, there are tons of ways to solve the problem, so ultimately do it the way that makes the most sense to you and your team.
Controllers are constructed by the ASP.NET MVC runtime and you should never be constructing them in your own code. It sounds like you don't really need a separate controller, you just need another class that you aggregate in the controller, and use as a service. This is perfectly acceptable. In fact, I would go so far as to say that in general controller should be delegating their work to other "service" classes and shouldn't have much responsibility (especially domain logic) in and of themselves.
I don't know the details of why this service class needs to know what controller it is being called from, but perhaps you can just declare an enum that defines the different use cases, and pass that in in its constructor. Actually having the service class know about different controllers would be a code smell for me.
I read the Pro .Net Asp.net MCV book over the weekend and it provides some good examples on setting it up and using it. However my question is what is the structure of an MVC project should be. I ran into problems once I started trying to transfer control from one controller to another. It seems that you can have multiple views within one controller. Also when you execute the Redirect("Action", "Controller") command it seems that the routing wants to look for the view within a sub of that controller. So my questions are:
Is there rule of thumb of 1 controller to 1 view?
Should you call another controller from a controller?
What is the proper way to transfer control from one controller to another?
You can have as many views/partial views per controller. The rule of thumb as far as one can deduce it from the MVC samples is, that a controller encapsulates a set of functionality that belongs together, e.g. listing products and creating, updating, deleting as single product.
You can use Html.ActionLink to route from one view to another. To call one controller from another, IMHO, makes only sense for partial views - however that depends on the problem.
Html.ActionLink or Html.RouteLink.
In ASP.NET MVC controllers exist in a folder called Controllers. Their names must end Controller otherwise things just don't work (you get an HTTP 404 error).
However, Model names don't have to end Model and View names don't have to end with View.
This seems inconsistent...why (from an MVC or design standpoint) do controller names have to end Controller?
Do other MVC frameworks have this requirement?
Edit
Since this appears to be the convention I am not advocating going against it (see Convention over Configuration!), but I want to understand the reasons behind it.
The controller convention is so routing can easily find the controller without additional configuration. Adding the required Controller ending makes it less likely that you would accidentally expose an object through MVC routing.
There is a built in convention for Views as well. By default views should be in a folder named for your controller and be named the same as the action calling them, this is what enables the method call View() in your action to work without specifying the view. I often find myself specifying the view anyway, but if you are looking for a convention this is definitely the one encouraged by the framework.
From a model standpoint you are correct, there is no standard convention. The reason for this is because the ASP.NET MVC framework never directly touches the models. It needs a convention for the controllers to find them from routing, and it needs a convention for views to find them from the controllers... but models are only accessed from logic in the controller so the framework doesn't need to know about them.
That being said I have seen most people build their Models just like they built their entities or Domain model before MVC. If you are using an active record pattern then name the models to correspond with the tables they are mapped to, if you are focusing more on a domain then name the models to correspond with the part of the domain they are modeling. Also, I have seen more and more people creating a set of view models that are just used for presenting data to the UI and are created by pulling in parts from various models in your domain. Models are definitely the least opinionated part of ASP.NET MVC, but that is a good thing imo since people have very different ways they like to work in this area.
That is just a convention not a requirement! You can change this behavor by customizing the DefaultControllerFactory or creating your own controller factory.
see here for more info. Also there are some examples in MvcContrib project which inject the controller from a Dependency Injection engine. check it out here.
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.