I was just wondering, if by moving complex if else statements and the resulting html markup to the code behind violates some 'MVC' law?
It seems like a great option when faced with inline if else statements that can become extremely unreadable.
It's not horrible to have conditionals in your view. I would keep them in the ASPX not the code behind. However, a conditional often indicates controlling behavior. Consider the following ASPX code:
<%if (ViewData["something"] == "foo") {%>
<%=Html.ActionLink("Save", "Save") %>
<%}%>
<%if (ViewData["somethingElse"] == "bar") {%>
<%=Html.ActionLink("Delete", "Delete") %>
<%}%>
This set of conditionals represents controlling behavior that is being handled by the view -- i.e., in the wrong place. This behavior is not unit testable. Consider instead:
<%foreach (var command in (IList<ICommand>)ViewData["commands"]) {%>
<%=Html.ActionLink(command) %>
<%}%>
In this example ActionLink is a custom extension of HtmlHelper that takes our own ICommand specification object. The controller action that renders this view populates ViewData["commands"] based on various conditions. In other words, the controller does the controlling. In the unit tests for this action, we can test that the correct set of commands will be presented under various conditions.
At first this might seem like a hassle compared with quickly throwing a few IFs into the view. The question you have to ask yourself is, "Does this IF represent controlling behavior, and do I want to ensure does not at some point break?"
I prefer not to use the code behind class in my views. This is not because it violates MVC by default, but because I found that the "natural" way (at least for me) is different.
When I face complex HTML markup that relates to purely view concerns, I usually write an extension method for HtmlHelper class in order to hide the complexity. Thus I have extensions like Html.MoneyTextBox(), Html.OptionGroup() and Html.Pager<T>.
In other cases when complex conditions arise, usually I missed something from the controller. For example, all issues related to the visibility, readonly or enabled of elements usually stem from something that the controller can provide. In that case instead of passing the model to the view, I create a view model which encapsulates the model and the additional info that the controller can provide in order to simplify the HTML markup. A typical example of view model is the following:
public class CustomerInfo
{
public Customer Customer { get; set; }
public bool IsEditable { get; set; } // e.g. based on current user/role
public bool NeedFullAddress { get; set; } // e.g. based on requested action
public bool IsEligibleForSomething { get; set; } // e.g. based on business rule
}
That said, the code behind is part of the view, so you can use it freely, if it fits your needs better.
I believe as long as it's a rendering code and it's in a "View" not in a controller, then putting it on code behind or inline won't matter. Just make sure that you don't write this piece of the rendering code in the Controllers actions (this way you will really violate the MVC pattern).
The codebehind is part of the View -- it's up to you if you want to put things in the ASPX directly or in the codebehind. MVC doesn't mean you have to code things all ugly in the ASPX :).
Related
I'm trying to have cleaner views for readability and the ease of modification.
I usually have for each view a couple of variables that represents the action URLs used in it:
#model IndexViewModel
#{
// controllers
string newsControllerName = nameof(NewsController).ToName();
// calls to actions
string removeNewsActionUrl = Url.Action(nameof(NewsController.RemoveNews));
string getNewsActionUrl = Url.Action(nameof(NewsController.GetNews));
string indexActionUrl = Url.Action(nameof(NewsController.Index));
}
So I can use them inside the view's data attributes for ajax calls in JavaScript:
<div id="newsContainer"
data-remove-url="#removeNewsActionUrl"
data-view-url="#getNewsActionUrl">
...
</div>
Then a friend of mine suggested that I shouldn't declare variables in a view because it's a bad practice and why not declare them in the ViewModel of that view in this case the IndexViewModel.
I know that views shouldn't have complex logic and should have the minimum of C# code, but is what I'm doing a bad practice? If so why? and is there a disadvantage or an advantage to have variables declared in the ViewModel of that view for this purpose?
From Microsoft docs views and view model:
Views are responsible for presenting content through the user interface. They use the Razor view engine to embed .NET code in HTML markup. There should be minimal logic within views, and any logic in them should relate to presenting content. If you find the need to perform a great deal of logic in view files in order to display data from a complex model, consider using a View Component, ViewModel, or view template to simplify the view.
I couldn't find anything related to this on this site.
I wouldn't want this stuff in the view model. It's superfluous there as there is nothing to be communicated between model and controller.
I don't see an issue with this - it's minimal logic and it is purely concerned with the view itself. Putting it anywhere else would be polluting another part of the codebase for no good reason.
That said, I don't really see any good reason for the code block - why not just inline it in the HTML attributes?
I have a project in which I need to check for and add a cookie, regardless of which view the user is currently on. I can place the code inside of the _Layout partial view within a code block, but I have doubts that's the conventional place for it. Where should it go?
View is generally wrong place to put logic.
Action filter is one possible way to centralize the code and allow easy customization, especially for something that sound so close to behavior of AuthorizeAttribute filter.
See Action Filtering in ASP.Net MVC for information.
public class MyCookieFilter : ActionFilterAttribute ...
[MyCookieFilter]
public ActionResult Index()
{
// The action method logic.
}
Side note: when searching for documentation be carefull to distinguish MVC and WebAPI classes - many have similar names and similar behavior, but can cause some confusion when applied to wrong objects.
Whilst looking at a theme I downloaded from the Orchard CMS gallery, I noticed that a Layout.cshtml file had this block of code at the top of the file:
#functions {
// To support the layout classifaction below. Implementing as a razor function because we can, could otherwise be a Func<string[], string, string> in the code block following.
string CalcuClassify(string[] zoneNames, string classNamePrefix)
{
var zoneCounter = 0;
var zoneNumsFilled = string.Join("", zoneNames.Select(zoneName => { ++zoneCounter; return Model[zoneName] != null ? zoneCounter.ToString() : ""; }).ToArray());
return HasText(zoneNumsFilled) ? classNamePrefix + zoneNumsFilled : "";
}
}
I know what the declared function does (calculates which zones are populated in order to return the width of each column), my question is- what is the correct use of the #function block, and when should I ever use it?
The #functions block lets you define utility functions directly in the view, rather than adding them as extensions to the #Html helper or letting the controller know about display properties. You'd want to use it when you can meet these conditions:
The functionality is tied closely to the view and is not generally useful elsewhere (such as "How wide do I make my columns").
The functionality is more than a simple if statement, and/or is used in multiple places in your view.
Everything that the function needs to determine it's logic already exists in the Model for the view.
If you fail the first one, add it as a #Html helper.
If you fail the second one, just inline it.
If you fail the third one, you should do the calculation in your controller and pass the result as part of the model.
Others have explained what #functions does so I won't rehash that. But I would like to add this:
If your view is typed to a viewmodel, I think a viable option would be to move this logic into the viewmodel to avoid cluttering your markup with too much code. Otherwise your views start to look more and more like classic ASP and I don't think anybody wants that.
I don't think there's anything wrong with using #functions or #helper in your view, but once you get beyond a couple of methods in your view, or even if the function is somewhat complicated, it might be worth refactoring to the viewmodel if at all possible. If it's code that can be reused, it may be a good idea to to pull it out into a helper class or an extension to the HtmlHelper class. One thing that is a bummer is realizing you just rewrote a piece of code that already existed because you didn't know it was hidden away in some arbitrary view.
From msdn blogs, #functions block is to let you wrap up reusable code, like the methods and properties
In this particular case, the people who have created the theme you are using probably were trying to keep it as a simple theme (only views, css and images).
If you need to write some code for a theme for Orchard, you have to turn to a module (as stated here: http://docs.orchardproject.net/Documentation/Anatomy-of-a-theme) unless you write this code in the view.
I am not sure it is worth the time to switch from a theme to a module only to get the size of a column.
Let's say I have a theoretical MVC framework that uses a ViewData object to pass data from the controller to the view. In my controller, let's say I have some code like this (in pseudocode):
function GetClientInfo()
{
// grab a bunch of data from the database
var client = Database.GetClient();
var clientOrders = Database.GetClientOrders();
var clientWishList = Database.GetClientWishList();
// set a bunch of variables in the ViewData object
ViewData.set("client", client);
ViewData.set("clientOrders", clientOrders);
ViewData.set("clientWishList", clientWishList);
showView("ClientHomePage");
}
And then in my ClientHomePage view, I display the data like so:
<p>Welcome back, [ViewData.get("client").FirstName]!</p>
<p>Your order history:</p>
<ul>
[Html.ToList(ViewData.get("clientOrders")]
</ul>
<p>Your wishlist:</p>
<ul>
[Html.ToList(ViewData.get("clientWishList")]
</ul>
This is what I understand MVC to be like (please correct me if I'm wrong). The issue I'm having here is those magic strings in the view. How does the view know what objects it can pull out of the ViewData object unless it has knowledge of what the controller is putting in there in the first place? What if someone does a refactor on one of the magic strings in the controller, but forgets to change it in the view, and gets a runtime bug instead of a compile-time error? This seems like a pretty big violation of separation of concerns to me.
This is where I'm thinking that a ViewModel might come in handy:
class ClientInfo
{
Client client;
List clientOrders;
List clientWishList;
}
Then the controller creates an instance of ClientInfo and passes it to the view. The ViewModel becomes the binding contract between the controller and the view, and the view does not need to know what the controller is doing, as long as it assumes that the controller is populating the ViewModel properly. At first, I thought this was MVVM, but reading more about it, it seems like what I have in mind is more MVC-VM, since in MVVM, the controller does not exist.
My question is, what am I not understanding here about MVC vs. MVVM? Is referring to variables in the ViewData by magic strings really not that bad of an idea? And how does one insure that changes made in the controller won't adversely affect the view?
Your understanding of MVC is wrong, it stands for Model View Controller but you are missing the Model in your example. This is the typed entity that gets passed back to the View to do the rendering. In ASP.Net MVC you would use typed Views that also type the Model within the View so it is checked at compile time. This eliminates the need for magic strings (second part of your question).
In MVVM you have Model View ViewModel. This is a way of binding a ViewModel directly to the UI layer via a View which is used a lot in WPF. It replaces the need for a controller and it's generally a 1-to-1 mapping with the UI. It's just an alternative mechanism that solves the same problem (of abstraction and seperation of concerns) but better suited to the technology.
Theres some useful info here which might help understand the difference.
Best approach to use strongly typed views
Models:
public class ContentPage
{
public string Title { get; set; }
public string Description { get; set; }
}
public class ContentPagesModel
{
public ContentPage GetAboutPage()
{
var page = new ContentPage();
page.Title = "About us";
page.Description = "This page introduces us";
return page;
}
}
Controller:
public ActionResult About()
{
var model = new ContentPagesModel();
var page = model.GetAboutPage();
return View(page);
}
View:
#model Experiments.AspNetMvc3NewFeatures.Razor.Models.ContentPage
#{
View.Title = Model.Title;
}
<h2>About</h2>
<p>
#Model.Description
</p>
for more detail check out here
I case of using string as keys of ViewData - yes, it will be a lot of exceptions if someone will refactor code.
It sounds like your understanding of MVC is very old, probably based on MVC 1. Things have changed tremendously in the last couple of years.
Now we have strongly typed view models, and we have the ability to use expressions in the view, which by default aren't compile-time validated, but they can be for debug purposes (though it slows down the build a great deal).
What's more, we don't pass model data through ViewDate anymore (well, not directly anyways.. it's still passed that way but the framework hides it).
In my ASP.NET MVC View I pick a sprite based on a boolean value set in the model like this:
<div class="sprite-icon_dog<% =(Model.HasNewDog ? "_new" : "") %>"></div>
This is ugly and I don't like it.
My objective is to use the sprite-icon_dog_new if Model.HasNewDog is true and use sprite-icon_dog if Model.HasNewDog is false.
What is a more elegant and more readable way to do this?
I think a HTML Helper would be the way to go?
public static string DogDiv(this HTMLHelper html, bool HasDog)
{
return "...."
}
In your view:
<%=Html.DogDiv(Model.HasDog) %>
Hope that helps,
Dan
It's ugly, but it may be the best option. If you move the logic to an html helper you are now blurring the lines between what is display and what is business logic. If you want to change your markup or css, you will be limited to what you can do unless you change code in the Html helper class.
In my opinion, part of that uglyness is getting used to the MVC model. One of the pillars of MVC is to provide a strict seperation between the display, business logic and data model, but if you start adding display logic in a helper it starts to negate what MVC is intended to do.