We are currently learning how to use c# at university, and we have been given a project that uses mvc, I would like to know what mvc is all about and how do we implement it? Any suggestions will be appreciated
No short sweet answer here will give it full justice, please have a look at this article.
wiki Model View Controller
or maybe even this
https://softwareengineering.stackexchange.com/questions/127624/what-is-mvc-really
As for the implementation of the pattern it will depend entirely on what your using to program with. I would advise search for mvc in the language or technology of your choice and follow a few examples, then get started once you understand the concepts of MVC
Have a look at this article from CodeProject.
It explains the MVC using a simple C# WinForms application.
http://www.codeproject.com/Articles/383153/The-Model-View-Controller-MVC-Pattern-with-Csharp
This is the best site to go. http://www.asp.net/mvc
For me if you want full control and testable web app without having to worry on the UI, I would use MVC. Everyone is going to this route. And so am I. =)
MVC firstly stands for Model View Controller.
Controllers
Controllers are nothing but classes which inherit from Controller base class and have different functions.
For example:
public class SchoolController : Controller
{
public SomeReturnType AllStudents
{
// Return all students
}
// More Functions here...
}
And these functions are responsible for providing response to the client request. When a client tries to open a URL (www.example.com/School/AllStudents) -
MVC does mapping to Controller Class SchoolController and then to the method AllStudents
Models
Now models are again classes. Models represent your database tables. So for example, if you have a student table in SQL then we will have Student Model in MVC. Example:
public Class Student
{
public int StudentId{get;set;}
public string Name {get;set;}
public DateTime DOB{get;set;}
}
Now in order to bring data from the database and put into our model, we use EntityFramework. So entity framework connects to the database and puts the data from the database table into our model.
Views
Now understand as I said earlier controller action will get called on client request. Now It is the duty of controller action(function) to provide response to the client requests. Now When the client requests for School/AllStudents, I can return it a simple list of strings, and it will get displayed on browser in the raw form. i.e. No formatting just the plain data. Now obviously we would not do that, instead I will make a good HTML page with the List of students and then send to the client.
So here comes Views in the picture. Views are simply HTML templates. In which you fill your data and return to the client.
In my mind I think of MVC as a routing mechanism.
To proceed further on learning MVC i would advise you to brush up your basic concepts on:
LINQ
Lambda Functions
Extension methods
Anonymous Types
These concepts are used everywhere in MVC.
Good Luck!
Related
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.
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.
Most of (nearly all?) the examples I find on how to set up an ASP.NET MVC project are accessing the database context directly in the controller.
Like this for example:
public class MoviesController : Controller
{
private MovieDBContext db = new MovieDBContext();
//
// GET: /Movies/
public ViewResult Index()
{
return View(db.Movies.ToList());
}
I also know that there are a lot of controls (at least for the aspx view engine) that you can bind to a table in the database directly as a data source, so that it automatically displays the data.
To me this feels weird and I would like some kind of separation between the presentation layer and the database. Some kind of business layer and/or data layer that maps data from the database to view models, before using them in the view. Is it just me or are the examples all like this because it's easier to do? Is there some great gain that I'm missing? I guess it's a bit faster, but it just feels like I shouldn't use the same models in my database as in my views. I finally found an example that feels more right, where the database models are separated from the view models. But it's one example of a hundred.
What are your thoughts on this?
I understand your concerns as I have the same. It's really a pity that most of the examples out there are not using view models. Because of this people are struggling a lot when they start implementing a real application that differs from the most trivial examples seen in those articles.
As far as directly accessing the database from the controller, I don't think that this is such a big concern. You really don't need to implement lots of layers of abstraction if you don't need them and if they don't bring any additional value to your application. Jimmy Bogard wrote an excellent blog post on the subject of limiting your abstractions.
Most MVC tutorials teach you how to do it simply because it can be done, and that the explanation of the Controller usually comes before explaining the Model.
Take the Movie App tutorial for example - http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/intro-to-aspnet-mvc-3
The majority of these tutorials first teach you how to display data using on the view, then using the controller to display in the view, then entering the data into the model and directing to the view via. the controller.
It's to keep the examples simple and focussed on the subject at hand.
I am quite new to ASP.NET MVC and MVC in general. Moving from the old school "spaghetti" design practices to WebForms was a big change, but this seems bigger (but better) in my mind.
I have some questions regarding data specific tasks.
For the sake of simplicity, say I have a database table called PIN with the column structure of PinId INT, Value VARCHAR(50) and another table called Entry with the columns EntryId INT, PinId INT.
I have an MVC view that takes in a string value as a PIN code.
The goal is to insert a row into the Entry table. To do this, I must lookup the corresponding PinId to the provided Value.
My question would be, where do I perform this lookup of data. I can easily do it in the controller where I am performing the insert of a new Entry object but is that right? Should this lookup be performed in the Model somehow?
In addition, I am following the instructions and practices outlined in WROX's Professional ASP.NET MVC 1.0. I have created a DataRepository class which handle all of my DB heavy lifting, and am utilizing the validation class as described in that book.
Any insights would be welcomed as I am a true newbie to MVC.
Cheers and thanks stackers!
Take a look at ModelBinders. This allows you to define how bind inputs from the data you are sending to your action to your Model objects. Your Action can also just take an argument of the type you want to save, and in your ModelBinder, you can do some lookup against the repository, etc.
There are many good blog posts on this if you do a search, now that you know to look at ModelBinder. Scott Hanselman has a good basic one:
http://www.hanselman.com/blog/IPrincipalUserModelBinderInASPNETMVCForEasierTesting.aspx
Never place search, add, update, delete code within a controller. Actually, there should be next to no code in the controller.
In the MVC world the controller is simply a means of getting a model from the view to your business layer and vice-versa. The aim is to have as little code here as is possible.
If you can use Linq2SQl then this would be a great place to put the entities. You can then use your data repository to do not only the heavy lifting, as you put it, but also all the other little things.
Linq2SQL will create a partial class. So, you could create another partial class which will do the CRUD and search work for you.
I come from the WPF side of the world and I am used to using the MVVM pattern quite a bit. I am attempting to learn MVC and am having a little bit of difficulty trying to understand where my boundries are in MVC. Here is my scenario:
I have 3 objects, Parent, Child and GrandChild. These are custom objects, not using the built in model stuff from MVC. I have a good handle on validation stuff. I have a good handle on how to get and populate my objects. But, I am struggling to find best practices on what to do with Controllers. What should my controller be responsible for? For example, should I have one controller that understands how to CRUD Parent, Child, and GrandChild? Or should those be separated? If they should be separated, how should I do that if, when I am looking at Parent, I want to see a list of Children.
Controller is used only for controlling the flow of the request-response. So, in your example, controller should never know how to CRUD them. CRUD logic should be wrapped in a Repository class of the model.
Take a look at the Official Nerd Dinner example and I personally love this part the most.
The Nerd Dinner app is a clean cut example. I agree with pushing CRUD to a repository, and in general, using the controller only for control flow.
However, in my experience with ASP.NET MVC (right or wrong), the controller ends up doing a lot of rearranging of the data before handing off to the view, and vice versa when accepting an object model as data from a form post. But again, it is just making a translation between what the View needs and what the Model needs.