I have been developing MVC 3 applications using Razor. I was wondering how much code would be acceptable in my views. There were situation where I needed to create, instantiate and use an object which wasn't included in the model and using ViewModel would make the model object bloated. Now when I look at some of my views, I find them full of server side codes. What would be the best practice when dealing with such issues?
I was wondering how much code would be acceptable in my views.
If by code you mean C# code then there should be exactly 0 to be precise. On the other hand it is perfectly fine to write HTML markup in your views and call HTML helpers.
There were situation where I needed to create, instantiate and use an
object which wasn't included in the model and using ViewModel would
make the model object bloated
Then it seems that your view model was not adapted to this view (since this view requires additional information). So change this situation by adapting the view model to it and including everything that it needs.
Now when I look at some of my views, I find them full of server side
codes. What would be the best practice when dealing with such issues?
Yes, that's horrible. Simply adapt your view models and refactor this code into your view models or controllers or even write custom HTML helpers.
Related
We're actually planning a really complex web application. At least for my own standards.
In the past we have always been using a combination of a server side MVC Framework (Codeigniter) and client side functionality (jQuery and plugins). We have simply written inline javascript code in our views. This worked as expected, but of course with several disadvantages:
no caching
duplicated js code
maintainability issues
...
My main goal now is to organize the client side code in an efficient and easily maintainable way. But I want to stay with the server side MVC because of the existing know how and some existing interfaces. Furthermore I want to reduce complex DOM manipulation with jQuery and "spaghetti code".
Now I thought about a combination of Backbone.js and Require.js but I really can't find a tutorial or any solid description about how to combine them with a server side MVC.
Is it even recommended?
In my old apps I got a file structure like this:
application (CodeIgniter)
assets
js
css
imgs
Are there any ideas or best practices?
Thank you!
To add to mexique1's advice, it might be worth looking at the backbone-boilerplate project. It should provide you best-practice solutions for many of the problems you're currently considering, such as the combination of require and backbone, the organisation of the client-side of your project, and the reduction of complex DOM manipulation (see templating).
The challenge, as you anticipate, will most likely be in combining the boilerplate approach with the approach you're used to. However, it will almost certainly be worth the effort since it should provide you a solid foundation for this and future projects.
I think Backbone is a good choice, and Require is not mandatory here.
Require will just help you organize your source code and maybe improve performance. I think you can start right away with Backbone, which will be the thing you are going to use most, and add Require later.
Regarding Backbone, yes it's easy to use to use its Model with an existing MVC application, provided it returns JSON. To load your existing data you will want to use the fetch method combined to url to adapt to your existing code, or your own method.
Generally, think about which models are displayed in which views. Backbone helps you think this way : I'm displaying Models represented as JSON data in Views which are made by HTML.
Also, for the view layer, it's very easy to reuse your existing HTML, because views are not tied to anything, no JavaScript templating or nothing.
Simple example :
<div id="user">
<span class="name">John</span>
</div>
var UserView = Backbone.View.extend({
render: function() {
this.$el('.name').html(this.model.get('name'));
}
});
var userView = new UserView({el: $('#user')[0], model: ...});
In this example the #user div reflects the state of a User model, with its name.
Also check the Todo App example in Backbone.
I have a some problems working with Areas. I am using Ado.Net Entity frame work and I generated POCO for my Model in the default Model, Now that I have to work in my Area (Admin Area) I cannot access the POCO. I thought of regenerating another POCO in my admin Model Area but not sure if is a right thing to do since it will be duplication and my database object are quite much. Please respond?
Areas are in reality just mini mvc structures (i.e. controllers, views, etc). If this has something to do with routing then make sure you are adding the correct namespaces to the DataTokens when calling MapRoute:
.DataTokens.Add("namespaces", new string[] { "MyNamespace.MyControllers" });
Or make sure you are specifiing the area in your action calls.
Honestly though I am thinking this is more of you needing to add a using directive.
More information would be helpful please.
I’ve been dissecting the Orchard CMS rendering and view engine in an effort to understand how it’s put together. I have discovered that neither RenderBody nor RenderSection are ever called. It is my understanding that the Razor view engine requires a call to one or the other.
What is it that gets around the requirement that RenderBody or RenderSection have to be called or an exception is thrown by Razor?
Is it the fact that there’s a custom view engine (ThemeAwareViewEngine)? If so, how does it handle parsing Razor syntax to generate the content?
Thank you.
It's actually the other way around. Razor itself doesn't require that RenderBody be called it's the RazorViewEngine that has this requirement. There can definitely be another view engine that uses Razor that has a completely different way of working. Take a look at https://github.com/Antaris/RazorEngine or https://github.com/Buildstarted/RazorSharp I've also written a markdown view engine that uses razor for some simple layouts.
From reading the source it looks as if they've created a few custom view engines. Their RazorViewEngine replaces the base class for razor generated files with their own custom WebViewPage which has a method Display of which Zone is an alias for. This is what allows them to render child views in addition it seems as if there are several types of Zones within the LayoutAwareViewEngine such as DocumentZone, ContentZone and so forth.
So in the end they've done a lot of custom code.
The title might not be easy to understand but it seems to me it is a basic design question when dealing with smart models.
I have a hierarchy of model objects that represent different types of document.
Say I have a view with different buttons, each one opens the document of the underlying object model. When I click on a button I have to display a view whose controller implementation depends only on the underlying model object class. How do I get this implementation ?
(It could be in the implementation of the button but then the question becomes how do I get the implementation of the button)
Should it be a factory that takes as an input the type of my model and returns my view controller ? Should it be my model that knows how to build its controller (seems dirty nè ?) ? Should I use composition ? Something else ?
I hope I am being clear enough. I am a bit struggling with this !
Your question is too abstract to give a specific advice. MVC pattern appears in many forms and in many technologies. For a web page it will have one shape, for a WPF app it will have another. In general there are both "view-first" and "controller-first" approaches. You can start with any one and see if it comes natural for your problem, if not -- refactor.
One other area you can explore is the area of modern composite application frameworks which provide out-of-the-box modular MVC\MVVM solutions. If you're writing for web, read about ASP.NET MVC and its best practices. If you're writing for WPF, read about MVVM approach and take a look at Prism, for example. You might find that your problem is already solved by existing tools.
I am writing a helper class to query my Zenfolio feed, return and display the images. Right now this code is split between a viewmodel and code in my controller. I want to pack it up into a helper class. Would all the code go into the helper or do i still split the code among different class with the helper only responible for generating the html? I have googled but not found an answer to my question.
Within the MVC pattern there is a clear separation between Model (data), View (html) and Controller (what gives the Model to the View).
To answer your question, No. Load your models in your Controller. Display them in your View. Html Helpers should only generate html for your view.
You may want to consider using a DisplayTemplate, which allows you use the same View template for every model of a particular type.
I wouldn't do any data access from the view. This sounds like a good use case for an action, and reusing code via the RenderAction method. You can mark the action as a child action using the [ChildActionOnly] attribute, which ensures it can't be invoked directly from the HTTP request, and return a PartialView result.
HTML helpers should really be used to generate HTML tags from data taken from the ViewData or Model (i.e. your view model in this case).
Data access in an HtmlHelper is only pain.
I've had the misfortune to inherit a project that had ad-hoc SQL placed into the HtmlHelpers by the 2nd developer on a project. The HtmlHelpers were beautifully written by the first developer, and the ad-hoc SQL pretty much nullified all of the time and effort put into having an service oriented architecture, having an ORM (the 2nd level cache became worthless), the unit of work pattern(transactions, worthless), and every aspect of design. Eventually, this 2nd developer had to make larger and larger HtmlHelpers so that different elements could share access to the data.
This was originally done for a display mode, and editing was accomplished through a pile of ugly custom javascript. All told, when the page rendered, it made 600 synchronous calls to the database.