We are in the process of moving our application to .NET. One of the main goals is to allow modifications to the application, per client, but not to the source code. We resolved this in the core framework by programming to interfaces and using a Dependency Resolver (having an option to override the base registration) and MEF.
Now when it comes to views (the UI the client sees) the templates seem static and if the client wants to add a new field to the screen it seems they would need to modify the view itself.
The only two things that I can think of is modifying the search path of viewengine. This would allow a copy of the base and changes to it would be picked up. Not really liking this as it's a copy of the code.
The other way, what we are doing now, is that we create a class that is a container to other objects that output HTML. Basically we have a PageObject, LabelObject, InputObject..ect that we can call render on and output HTML. Since they are classes we can use the same methodology as for the rest of the application of giving slice in points. Going this route we really are not using the viewengine for rendering but just for combining all the partial views. Seems kind of clunky.
Is there a different way to accomplish this goal or a different viewengine that I can use to meet the goal of allowing customization for clients without touching the base view? I know HTML is not an object but seems there has to be something in between ASP.NET WebForms and ASP.NET MVC when dealing with HTML and allowing for customizations.
I would create a strongly typed partial view or template (DisplayTemplate or EditorTemplate based on requirements) whose #model is a collection of things that are rendered as inputs and labels. Allow the client to add/remove items from the persisted collection (i.e. in a database) and your problem is solved using the built in ViewEngine.
Related
I just started out with Umbraco for my own projects because it is cheap in comparison to Episerver. Coming from the Episerver paradigm of strongly typed Page/block types and doing everything programmatically, i now find it hard to get into Umbraco in the way i hoped to.
I know how to create simple applications but i was hoping to define my Page Types like classes with properties that Umbraco then treats as Pages. My goal is to be able to create a hierarchy of page types where certain pages inherits properties from its parent page etc.
If I have a ArticleListingPage I want to inside of it's controller list all types of article pages. For example if I have a ArticleBasePage with the properties MainBody, Heading, Introduction then I want these to be inherited by ArticlePage and ArticleLongReadPage. Whenever I want to list these I want to search for pages of type <ArticleBasePage> and loop through the collection and render these. I don't like working in the UI I simply want to create a hierarchy of classes(that are pages) just like I would do in Episerver.
Is there any way to do this? Or a guide maybe? I don't like the approach of creating pages in the UI, I want my pages to be of a certain class so I can get the benefits that comes with that
Umbraco is vastly different from current Episerver versions (7+) in terms of managing the content model, but you can achieve somewhat similar code-first features to enable inheritance.
You may want to have a look at uSiteBuilder (available as a NuGet package).
Some more information available on Jon Jones' blog.
I'm not sure if this is the right place for my question, but i will give it a try.
We are starting the development of a new product wich will use asp.net mvc 3 razor as the presentation layer. The application has about 7-8 different roles and all the roles have different views on wich the data will be displayed.
I've build a nice framework with the help of NHibernate and the implementation of a couple design patterns, so this side of the applicatie will be easy to adjust and apply maintenance to.
I want the presentation layer to be as adaptive as my framework and that's why i'm trying to figure out a way to have as less views as possible for all the different kind of roles but with full functionality. What kind of implementation do you use for distributing views to the end-user based on his role?
I thought about using jquery templates, but with the current possibility of views and the razor syntax it sound a bit unnecessary and not the preffered way to go.
Any information that i should keep in mind while developing this application will be nice, think about, common mistakes, best practises and suggestions etc.
Looking forward to your replies.
One way to reduce the number of views would be to use IsInRole() (or an equivalent if you have something custom) in combination with partial views. In the most simple case, you could have one view that also renders partial views within it based on specific roles. Something along the lines of:
#if (HttpContext.Current.User.IsInRole("admin")) {
#Html.Partial("_StuffForAdmins")
}
Depending of your situation, some partial views could then be shared across multiple different roles, reducing duplicate code. User interface elements that are publicly accessible by all roles could just be placed on the view itself without role checking.
EDIT: An alternative syntax is:
<div>
#if (Context.User.IsInRole("admin"))
{
#Html.Partial("_StuffForAdmins")
}
</div>
On Web Forms we have UserControls. These controls have a code-behind and can be used in different projects/solutions not depending on other things.
I want to create a control that renders some controls and would have some links that would "trigger an event". I want them not to be attached on my website, I want to be able to use the same "control" on another website. What is the equivalent in MVC? Is it possible to compile a view with a controller and use the DLL elsewhere?
The closest functional equivalent to WebForms-style reusable user controls in MVC are html helpers. An html helper is a method that returns some markup. The recommended approach is to implement them in the form of extension methods off HtmlHelper or some other property of an MVC page:
public static IHtmlString MyControl(this HtmlHelper helper, string value) {
return new HtmlString("<p>" + value + "</p>");
}
You can add this method to your MVC project directly or you can add it to a seperate class library. The only thing that the class library needs to reference is System.Web.Mvc.dll for the HtmlHelper reference (it might also need System.Web.dll if you use more types).
You usually call them from your view like so (this example uses the Razor syntax that's new in MVC 3)
#Html.MyControl("my value")
While superficially html helpers emit markup just like User Controls, there are significant differences. The most important one is that MVC views don't have the concept of the WebForms page lifecycle. This means that unlike user controls, html helpers are rendered in a single pass. There are no mulitple phases like Init, Load, Render etc in WebForms where you can hook up server-side events to interact with other controls on the page.
Depending on what specific kinds of events you are talking about there might be appropriate MVC-centric techniques to solve your task. Could you provide more detail on what you want to do? Html helpers can be quite powerful. For example the built in MVC input controls like TextBoxFor can hook up client-side validation etc.
Since "events" don't exist in the same sense in MVC as they do in WebForms, meeting all your requirements will be quite tricky.
For the UI layer of the UserControl equivalent, you should use a PartialView, possibly located in the Views/Shared/Templates folder depending on if you want it to be associated with a certain Model type or not.
For the back end (the "event"), you should probably implement a Controller that you could send the requests to from your links, and that supports all the behavior you need.
To use these features in various projects, you then have to copy both the controller and the template/partial view. Admittedly, it might not be as simple to re-use as a do-it-all user control from WebForms, but that is a limitation that comes with a clear separation of concerns, and that would be apparent in a well designed, layer based WebForms application as well.
Update in response to a comment on the "limitation" of separation of concerns I mentioned:
The controller can of course be distributed in a separate assembly, with it's own test assembly etc. However, including the controller assembly (or assemblies) and the partial view/template with the front end code is arguably one more thing to do (i.e. possibly fail to do) than just copying a user control with it's code-behind (that are stored next to each other).
So I am creating a C#/Winforms application in a model-view-controller pattern. My view-controller needs to instantiate multiple groups of objects. The object groups are elements of the model and elements of the view. So for example a textbox and the model to go behind that text box.
I'm wondering if the best way to do this is to put everything in some sort of collection and tie them together with a key?
In the WinForm MVC apps I've built, I typically don't allow the controller to instantiate anything (I try and keep the "new" keyword out of my controllers).
If I need an object I ask a service for it, and internally that service is going to fetch that object from a data source (repository or the like), or in the case of a new object it will likely utilize some kind of factory to get me a new object (with any necessary pre-filled properties already set to default values, rules run, etc.).
The way I like to think about this sort of problem is this: how would I make this work (and make it reusable) if I didn't have a GUI for a view, but instead had a command-line input for my view? The logic to create/add/delete/update the model should be somewhere in your domain, not in the controller. Then the controller just becomes the mediator between the model and the view. The view becomes an I/O mechanism that is just a prettier version of a command-line interface.
Hope that makes sense.
Have you considered using WPF instead of WinForms? It has a nicer MVC-like model and built-in databinding that is much more powerful. It would probably solve your problem and help you build with more modern technology besides.
Perhaps you should design your model to match what the view needs? Then there would be only one model for the controller to pass on to the view.
I am primary a web developer but I do have a very good understanding of C++ and C#. However, recently I have writing a GUI application and I have started to get lost in how to handle the relationship between my controller and view logic. In PHP it was very easy - and I could write my own MVC pattern with my eyes closed - mainly because of how PHP is stateless and you regenerate the entire form per request. But in application programming languages I get lost very quickly.
My question is: how would I separate my controller from view? Should the view attach to events from the controller - or should the view implement an interface that the controller interacts with?
If I was you I would expose events from an interface of your view. This would allow you to make the controller central to the entire interaction.
The controller would load first and instantiate the view, I would use dependency injection so that you don't create a dependency on the view itself but only on the interface.
The controller would access the model and load data into the view.
The controller would bind to events defined on the view interface.
The controller would then handle saving of data back to the model via an event.
If you wanted to you could also use an event broker which would void the need to declare an interface per view. This way you could bind to events through attributes.
This would leave you with the Controller being dependent on the model and the view interface, the view being dependent on the data only and the model having no dependencies.
Some examples of the above design thinking can be found in CAB and the Smart Client Software Factory Link To Smart Client. They use the MVP pattern but it could equally easily be applied to the MVC pattern.
Most every GUI framework (from MFC to SWT to whatever) is already MVC based. In fact, the MVC pattern was first created by Smalltalk-80 and later first really used for GUI development.
Double check and look at the standards and suggested practices for your GUI toolkit of choice. Sometimes MVC won't be a good pattern to work with when solving a certain problem or working with a particular toolkit.
Remember: MVC is a great pattern but isn't a one size fits all solution, don't try and force a problem into MVC when event-based or functional style programming will make your life easier.
Imagine this GUI:
The Zergling unit is presented to the user as an alien icon. You can see that it is in its idle animation. Call this the View.
The player moves the unit by clicking on it and a target location. You can subtitute the player for an AI if you want. Call this the Controller.
The HP and attack range of the unit is calculated every game frame when the unit is in combat. You can change this data to make the Zergling into a range unit. Call this the Model.
Keep this analogy in mind and extend it for your MVC designs.
The imortant thing for you to remember, is that in your MVC setup the Controller must know which View to call, but the View must know nothing of the Controller.
So your View must provide a generalized way for Controllers to interact with it, so that you can have several different Controllers call the same View (a standardized graphical output of some data provided as parameter, for example).
This gives you flexibility:
If your customer wants PDF output of
something you only provide HTML
output for, you can get away with
writing a new PDF View to be called
from the Controller with the same
parameters as the HTML View.
If your customer wants similar HTML output of a different data source (say), you can get away with coding a new Controller that provides a different data set to the same old HTML View, which gives the same HTML report just with other data.
If you keep your View detached from specific Controllers, and put the knowledge about which View to call from your Controller, you're well on your way.
Your controller should definately bind to events defined on an interface the view implements.
How you go about doing this can be the tricky part. Dependency injection? A view factory? Have the view instantiate the controller it wants? It really depends on how complex the application is going to be.
For something really quick and simple I would start with having each view construct it's controller and then look at other options if it needed to get bigger. Personally I think a full dependency injection framework is overkill for half a dozen forms :]