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.
Related
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.
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.
How do I create a view in ASP.Net MVC 3 that defers creation/rendering of a portion of the view to another view/controller, without knowing at design time what view/controller will be deferred to?
I have a Dashboard view/controller that uses a Layout page. the dashboard view does most of the work of rendering the overall screen. However a certain placeholder section of the overall screen will differ based on business rules, configuration, user interaction etc. There are three separate plugin views/controllers that may need to be rendered in the placeholder section. How do I instruct the Dashboard view to render a specific plugin view once the Dashboard controller has determined which plugin should be visible. I have accomplished this already by putting flags in the Dashboard model and then having conditional logic in the Dashboard view call Html.RenderAction with the appropriate parameters based on the flags. This seems unsatisfactory and I would assume there is already a simple built in functionality for this kind of scenario, please advise.
Thank you
You are really asking "how do I dynamically render partial views who's identity is known at design time."
One can get there two ways, either through Html.RenderPartial or Html.RenderAction. And both have their place. If the main page "knows" enough to have the view data, then RenderPartial is your the better bet as it is a bit more efficient than RenderAction. If you only know, say, a unique identifier for your portal widget than RenderAction works because you've now got a fully capable controller method that can do things like go back to a database and render a view.
You could write your own htmlhelper and use that in your view instead of using the flags.
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'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.