Develop Reference

Avoid explicitly marking a property as not modified in Entity Framework

Whenever I update an entity, I need to include every field in the form as a hidden input, so that it's value doesn't get set to null.
Setting the property as not modified, like the code below, prevent this. But this code is abstracted into a generic IRepository interface encapsulated by an UnitOfWork class, so I can't specify non-modified properties for each entity.
Entry(entry.Entity as MyModel).Property(e => e.AProperty).IsModified = false;
Is there another way to do that?

You could use a MVVM architectural pattern. The Model View ViewModel (MVVM) is an architectural pattern used in software engineering originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.
Model : Model refers to your application data. In a real world ASP.NET web application, your data will typically be stored in a SQL Server database and your UI gets it from the server by making AJAX requests or some similar technique.
View Model : View Model refers to your data and UI level operations that you wish to perform on the data. The operations may include business validations or conditional checks or updating certain parts of the web page. You can think of View Model as a wrapper over your model data that adds UI level operations to it.
View : View is the user interface of your application. A View interacts with View Model to invoke some operations. A View is updated whenever data from the View Model changes. For a web application a view typically takes the form of an HTML document.
Here is a real world example using ASP.NET and EF. http://blog.tonysneed.com/2014/05/28/real-world-mvvm-with-entity-framework-and-asp-net-web-api/

Interface between Controller and Service Layer

I am a newbie to .Net MVC and my question today is regarding the MVC pattern.
In our application we have a Service Layer which talks with the DB.
The Controller is Currently talking with the Service layer to get the values from the DB.
Our new Manager requires this service layer interaction from the Models and not from the Controller.
He does say that this architecture is to achieve a thin Controller. We are now starting to port the service layer interaction from controller to models.
And here comes my question. Apart from having a thin Controller, is there any other benefits from enforcing this pattern.
I would like to know the advantages and disadvantages of both pattern.
Some links would also be helpful

Why you shouldn't call services from your ViewModels:
ViewModels are supposed to be classes that contain some data that is interchanged between the View and the Controller. They should not perform any action or retrieve further data. They are dumb models, they don't do anything expect transport data.
What is a View Model
If you are having trouble understanding what a View Model is and what it isn't, think of it like a subset of your model. It only contains data that you need to display on a given view at a given time.

There are 3 types of Models - View Model, Domain Model and Data Model. Check here.
If you are talking about View Models then its a bad idea. There are ways to achieve a thin controller, but ViewModel never should interect with services. If its possible a Controller Action should only invoke a service and throw the result to View. Like this:
[HttpGet]
public ActionResult GetAnimals(int id)
{
var viewModel = new AnimalsService(id).GetViewModel();
return View(viewModel);
}
But in reality many times you can't do that for some obvious reasons. There are few things you can do though. Like don't validate models in controller, you can do that in service layer. Don't hesitate to create more services for different jobs, like pagination, context related logic or some third party api invocation. Create helper or utility classes for repititive codes. Also I think its ok to write fat services.

Should I inject services into my MVC views?

We're working on some kind of Cloud CMS using ASP.NET MVC technology, and have found some obstacles on the way. There is a number of parameters user could change thru the control panel that we need to end up in Views. For example, Facebook application id to initialize the Facebook JS API. Or additional text to be shown on the page. Or background picture. For now we're not using DI to transfer this parameters, instead we're adding them to the ViewModel, but this ruin the ASP.NET MVC way of working with models (e.g. form validation, bindings etc.)
It looks like that using DI to inject services for providing parameters, texts and pictures could make my views less dependent on controllers specific, and there is even some Microsoft technique to do it http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection#Exercise2. However, there are a lot of answers on forums against injecting services into Views using DI.
So the question: what is a right way to inject some services into Views? Or I shouldn't do it at all and something is wrong in the application design?
UPDATE: some real code examples (now we're using Model to inject the services)
Injecting texts from database (they have to be user-editable, as it is CMS):
<div class="steps">#Html.Raw(Model.Texts["Main", "Step2"]</div>
Injecting translations from database (actually, it is localization):
<div class="gonfalon">#Model.Translations["Title_Winners"]</div>
Injecting parameters (from database, could be request-specific; for example, if the site has different domains, facebook application should be per-domain):
Facebook.Initialize(Model.Parameters["FbApplicationId"], Model.Parameters["FbApplicationSecret"]);
The problem of current approach is that this code has taken from contest mechanic. It is definitely out of contest business scope to deal with custom texts, translations or facebook application Id. Also it ruins the Model as model models not actual business domain but deals with a lot of things actually belongs to View (like translations and custom texts)
UPDATE 2: Have modified the snippet from the answer below to be a bit more generic:
public static class WebViewPageExtensions
{
public static I ResolveService<I>(this WebViewPage page)
{
return DependencyResolver.Current.GetService<I>();
}
}

No, you shouldn't inject services into Views, but...
For scenarios such as theming where you want to give the theme developer more power, just one model isn't enough. If your model contains the current post for example, how can a theme designer asks for a list of categories for the sidebar? Or for a widget?
In asp.net mvc you can use extension methods to offer that functionality.THe extension method will use the dependency resolver to get the service. This way, you can have the needed functionality in the view without actually injecting a service.
Note that calling the business layer to update the model is still a violation of Separation of Concerns. THe services made available to the view should contain only read model or general utility functionality.
An example
public static IMyViewServices MyServices(this WebViewPage view)
{
return DependencyResolver.Current.GetService<IMyViewServices>();
}
IMyViewServices lifetime configured in the DI Container should be per http (scope) request

No, end of story. Why? Here is why:
Your view only needs to know what the view model it's going to be working with to present that model. There are couple of reasons for this but the biggest one is the separation of concerns. Keep your view as stupid as possible. You will see that this seperation will give you a clean application structure throughout the way.
There is a number of parameters user could change through the control panel that we need to end up in Views.
I'm not sure what you exactly mean here but this is why there are view models. Your business layer will shape models up, your controller will simply map them to your view models and pass them into the view (presentation layer).

This really depends on how much or little you want your controllers to do and to what degree of separation you want to achieve.
In my world, the "controller" in an MVC app does as little as possible because I have a service layer handling all of the business logic and a data layer above that handling all of the database interaction.
On a GET, the controller will simply call a service method that will build the view model and hands it back to the controller and the controller passes it on to the view. On POST, the view posts data to the controller which sends it off to the service layer for validation, saving to DB, etc. The service is injected into the controller's constructor.
I'd be more than happy to post code examples if you'd like to see them.

Understanding MVC4 Controllers

I'm fairly new to the .net Framework and the whole MVC programming philosophy. Could someone clarify and give me a basic explanation how controllers interact with sites using C#? I understand how to code in C#, and I understanding some aspects of the framework, but I don't see how they all tie together.

Model - Is a data structure that represents some kind of object (usually one). It's purpose is to read, write and manage the access to the underlying object with the aim to persist application state.
View - Is the components that are used to display a visual interface to the user, perhaps using a model. It might be a simple table or a complex combination into a full web page.
Controller - Is the user driven application logic layer the sits between views and models. It handlers user interaction, loads models, and sends views to the user. It determines what model is sent to the view depending on user requests.
The overall folder structure for an application might look like this.
>> Website
>> Controllers
>> Models
>> Views
In C# MVC each controller must have the suffix Controller in the name, they must extend Controller class and have a folder of the name prefix (without the Controller) in the views folder. This folder will then contain all the views related to particular actions on the controller.
Controllers can contain any number of actions defined as public functions. By default when returning a result from a controller action the name of the view must correspond with the name of the action. However you can also specify a view by name. When loading a view from a controller, it is possible to send an object as a model to the view and there by generate it's content.
Controllers can load any model and are not restricted in any way.
An Account controller defined as below with an action Login. The controller is placed in a AccountController.cs file in the /Controllers folder, and any views for this controller (Login in this instance with filename Login.cshtml) are placed in the /Views/Account folder.
Note: The naming convention has to be right as the names are used between the controllers and views to link the data.
public class AccountController : Controller
{
public ActionResult Login(string returnUrl)
{
if (User.Identity.IsAuthenticated)
{
return RedirectToAction("Index","Site");
}
return View("Login", new LogOnModel());
}
}
would be accessible via http://www.mysite.com/Account/Login. If the user is authenticated, the controller will redirect to the main site controller, if the user is not logged in then they are shown the Login view which loads data from the LogOnModel specified.
This is really just touching the surface of what is possible. Read some online information on some excellent articles by ScottGu which go into much more depth and talk you through how to use MVC.
ASP.NET MVC Framework Overview
ASP.NET MVC Framework How To - Part 1
// Part 2
// Part 3
// Part 4
Note : These articles are slightly outdated as they were written for MVC version 1 back in 2007, but the concepts of how the Models, Views and Controller interact still apply.

Controllers serve somewhat as an internal web service. They expose your server side code to your views and allow them to call the controllers. In terms of pattern, most people believe that controllers should be as thin as possible. If there is heavy lifting or other business logic, you should abstract it to another part of your application. In my eyes, controllers are there to provide the view with something to call, and then to return that data whether it be text/html, json, or xml.
Here's a great wealth of information, straight from the source: http://www.asp.net/mvc/mvc4
Specifically to the site, I'd highly recommend the tutorial. It will give you a much clearer picture of how Models, Views, and Controllers interact and depend on one another.
http://www.asp.net/mvc/tutorials/mvc-4/getting-started-with-aspnet-mvc4/intro-to-aspnet-mvc-4

A controller is a class which has methods, those methods are called actions, you atach those actions to "views" (cshtml files).
//This is your controller
public class HomeController : Controller
{
// This is your action
public ActionResult Index()
{
return View();
}
}
You can right click the "Index" action and select "Add View..." this will create a new view atached to that action.
In order to access that view you will do something like: localhost/Controller/Action
In this case it should be: localhost/Home/Index where Home = Controller, Index = Action
You should read about the MVC pattern
Microsoft has some really good tutorials for beginers

Controller in ASP.NET MVC is an object that handel your app logic in response of requests. It will be created per request (e.g. a HTTP request) and will be available until response created by View layer. After that it will be an unusable object (and soon GC will free its allocated memory) and for another request a new controller object must be created and so on.
I think by this definition it will be obvious why it must be lightweight and how you must use it.

Asp.NET MVC is MVC or MVP?

As I've been reading this article: http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod, MVC was explained like this:
In this diagram, View-Model is observer pattern where any changes in Model notify View's Update method to update the states of Views and passing its current state to these Views.
Relation between Views and Controllers are defined in Strategy Pattern where Views get concrete controllers and run the algorithms in controllers as defined by Strategy Pattern.
So Controllers update models and models notifies views to update their states.
However, for some reason I couldn't visualize the same logic for Asp.Net MVC as Controllers have access to Model and pass these models to Views but views uses Models directly to get their properties,etc to update their states but I couldn't fit the observer pattern between Views and Models in Asp.Net MVC.
Could some one please explain what I am missing out?

ASP.NET MVC upholds the stateless nature of the web, so once a view is rendered there is no way for the controller to know about changes to an instance of a model object.
This is different to a stateful platform like Silverlight or WPF. The fact that they're stateful allows a controller (or ViewModel if you're using MVVM) to observe what's happening on the UI, make changes to model objects, and then have the view update itself accordingly.
In ASP.NET MVC when data gets passed from the controller to the view, it's a one-way trip. There's no equivalent of the View.Update() method; the view gets rendered once and then that's it. There's also no way for a view to call back to a controller, as per Controller.AlgorithmInterface. You can achieve something similar with an AJAX callback but then you'll have to use some behind-the-scenes magic to repopulate the controller with the state data (e.g. by passing an object ID from the view back to the controller).