We have a project where we have created 2 separate areas to be used by administrators of a site, depending on which Role the authenticated user belongs to. There exists some overlapping functionality between the two areas, but not enough that we would combine them into a single area. So what we have done for the UI is create some partial views that are included from similar views within the two areas, however I'm having trouble deciding where to physically place the partial view.
It doesn't make sense to place it in ~/Views/Shared, as none of the root-level views use this particular partial view. It also doesn't make sense to place the file in ~/Areas/[Area]/Views/Shared, as neither of the areas directly "owns" this partial view.
What would you consider a best-practice location in this scenario?
I think ~/Views/Shared is not the best solution for you here, although those partial views are really shared between two Areas, which are separate controllers, as I assume.
However, you can use
Html.Partial(pathToView, model)
function to include the partial view, which may be put wherever you want.
Even the example you've mentioned:
Html.Partial("~/Areas/[Area]/Views/Shared/PartialViewFile.cshtml", model)
Or:
Html.Partial("~/Areas/Shared/Views/PartialViewFile.cshtml", model)
This solution seems more relevant for me, as all Areas share views, and they do not belong to the particular area.
Related
I have a project in ASP.MVC5 and Im in the middle to decide if I use Areas or not.
The project will have 3 types of applications inside:
Customer users
Interal users
Support users
The hole application will share the login page, and depending on the user type Im planning to redirect to the right Area.
So I was thinking on the above idea or just use the default structure and then have:
Views/Customer/and here my views
Views/Internal/and here my views
Views/Support/and here my views
Any advice?
If you are going to have similar controllers and models and views for each different "module" (Customer, Internal, Support) then areas would help organize it. For example, if your customer is going to have OrdersController (Edit, Display, Create etc.) and the corresponding models and views and your Support will also have similar controllers, models and views then it is worth creating areas. That way your routes will look like this:
~/customer/orders/1/edit
~/customer/orders/create
~/support/orders/1/edit
~/support/orders/create
But if that is not the case, then it is not worth it because areas do tend to make things a little more complicated.
I would start with the simple, no areas, structure firstly. If you see the need for areas then create them.
Currently i am investigating if MVC is the way to go for the new major version of our web application. We have an existing web application with webparts, dynamically rendered according to some user settings. Each webpart has its own data and own logic (for example, one webpart with user information, one webpart with currently logged-in users, one webpart with appointments etc. etc.).
What we need to accomplish (i think) is to render a single view, which contains several partial views. Each partial view represents a different model, and has its own logic.
I figured out how to put multiple partial views within a single view, but i don't know how to handle the business logic for each view (in "partial controllers"? if possible at al?), and handle the model for each view?
So the main purpose is to render a page with multiple dynamic views (according to what the user has configured), each with its own logic and data. And then when, for example, a button is clicked in a partial view, the corresponding controller is called to handle the event, and returns the updated partial view. The partial views need to be loosely coupled, and updated async.
From what i've seen so far the most tutorials and documentation are focussing on MVC in general, not on how to separete the business logic and model for eachr partial view.
So I'm not asking how to do this, but:
Is it possible to easy accomplish this with MVC 4 or 5?
Does anybody know a good real-life example or tutorial about this?
I hope anyone can point me in the right direction or share some thoughts on this...
You could make one or more controllers with an action for each webpart.
Group all related webparts in the same controller but make an action and View+ViewModel for each webpart. Then use the Html.RenderAction method to call these actions (and have your webparts placed) on your page/main view.
DISCLAIMER: This said, each call to Html.RenderAction creates a complete mvc flow, instanciating a controller, model and view and finally renders the whole thing and passes the value to your page/main view. Having lots of Html.RenderAction has the potential to slow your page creation a lot. You could look into DI/IoC like Unity and consider reusing controllers, or just look into System.Web.Mvc.DependencyResolver to handle the creation of controllers yourself.
For my site I want to implement a banner control that will be on the left side of the site.
The banners will be stored in html in the database and each one will have a rating. Then using the rating each one will have a number of occurrences (percentage).
Do you think that there is a feasible solution to put all this flow in a separate dll? Is that even possible in the mvc architecture. I would prefer to do it as a partial view and have everything in a separate dll the partial view and the data access layer. Do you think that this is a good solution?
What is your approach when you have to implement a "user control" (partial view) ... do you put it in the website project or a separate project?
Is there any other way to implement this instead of using a partial view?
Thanks, Radu
There's a few choices that you have-
do it as a HtmlHelper extension. Probably not ideal for this kind of thing as the managementof the banners to display and the associated logic is really the concern of the banner component/widget/partial.
Do it as a partial view and use Html.RenderPartial(object Model) to call it. Now the logic is in the partial view, but there may also be some application logic that shouldn't really be going into the view and really belongs in the model or the controller. Also, you can end up with fat view models being passed to the main view that have to also carry a view model for each partial rendered in the main view. I think in some situations this isn't ideal, particularly when the data in the view models for the partials has nothing to do with the data for the main view. Which brings us to...
Do it as a child action with an associated controller and partial view. The logic will be nicely encapsulated in the controller and the partial view will simply render out whatever it's passed from the BannerController.
You could certainly put this in a separate assembly and set it up as a Portable area. This way, you can embed the partial views in the assembly and to reuse the widget would be a case of just dropping the assembly in the bin folder and referencing it in your main application project (you may also need to set up some configuration perhaps).
Whether I would personally do it this way or not depends on reuse for the component; to be honest, I'd probably set it up inside of an area in the main application to begin with and then, if I find that I need to reuse it, move it out to a portable area.
I also generally like to keep the data access logic in a separate assembly and use the repository pattern along with IoC to inject repositories for doing data access into controllers.
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 our standard web forms ASP.NET solutions we typically have a range of user controls within the master page and determine whether they display or not within their code behind. What is the best approach within ASP.NET MVC to achieve the same goal?
You could obviously put if statements within the master page or the partial view but that strikes me as messy and breaks the principle of keeping business logic out of the view. It also requires either putting the necessary information into all view models, or inheriting from a base controller which seems like a lot of messing about for something so simple.
I was thinking about using RenderAction and returning a totally blank view to prevent any output - is that a good pattern?
breaks the principle of keeping business logic out of the view
It is not business logic. It is presentation logic when you determine whether to display something or not. It is okay to have it there.
You can make decision whether to display something or not and set up a few flags in the model (you can make BaseModel or MasterModel for example). Then your master views, partial views themselves or HTML helpers will perform conditional rendering based on these flags.
As to the clean separation of concerns, yes, the WebForms could seemingly do it but it was rather a huge abstraction of the underlying mechanisms. Often it results in having business logic in the code-behind, meaning, in the presentation layer where business logic belongs no more than it belongs to the views.
You could avoid the messy "If" statements in view by creating a Html extension method as mentioned in my recent post http://www.rajeeshcv.com/2010/01/asp-net-mvc-conditional-rendering-partial-views/
Thanks,
Rajeesh