Hey guys,
We are looking to migrate to MVC from the traditional coding,
do you have resources to start with?
Available tutorials in asp.net is confusing.
Thanks!
is it ok to start with MVC 3 even I have no idea what is MVC is?
Well, you wouldn’t put Windows 95 on your new computer would you?
MVC3 is the current version.
hahaha that is a very good one!
I mean, will I need to learn MVC1 to catch up with MVC3 I am talking about pre-requisites.
Can I ask you a very obvious question?
VIEWS is the part where HTML is…
CONTROLLER is the part where you will execute your methods
and MODELS is where the SQL is?
(please correct me if im wrong)
In a very simple example How can I fetch a record from my SQL SERVER2008
using the 3?
Thanks
3 is a version number. Don’t worry about learning 1 or 2, its all in there.
I am totally lost in model… I can’t find on how to start connecting to the database? Anyone have a snippet?
Are you using a Linq to SQL datacontext?
I read about it… is that the simplest way? Actually I tried it but I am lost in the middle. I saw the database on the server explorer panel, but I still can’t figure it out how it will connect to my pages…
I have a class already that has get and set things…
Why are the .net guys are so complicated?
Get the book I mentioned. Then if you have questions you’ll at least have the ability to understand the answers you receive and those that answer will know where you are actually at in the process.
When you say “traditional coding” what does that mean? Have you worked with ASP.NET and not used Linq to SQL or Linq to EF?
If you don’t have the money for a book, here’s the next best resource for beginners in MVC.
Make sure to watch the entire “Essential Videos” series on the left of the page by Pluralsight, before reading the extra documents on the page. But read them all too.
To clarify one of your answers, at the simplest level, the “model” is the part which contains your actual business model. The controllers job is merely to coordinate communication between view and model. You shouldn’t be making any business decisions within the controller.
The tutorials above start of by using models that are both persisted to the database, and used in the views for display. For now, do this, and get used to it. You will later be introduced to the idea of a separate view model, but you might not understand why they are needed until you run into some of the pitfalls of using your business model in views.
Interacting with a database can be done in several ways, but most involve the use of a persistence engine. MVC itself does not come with a persistence engine, although the latest tools update sets up the initial MVC project for use with the EntityFramework engine. You can remove it and use others if you wish. You must first choose your engine before we can help you connect with it. Otherwise, we’d be taking stabs in the dark, and making assumptions.
Mostly, have fun with it.
I am curious about the “separate view model”. Could you define that and maybe give a broad brush stroke about the pitfalls of using your business model in views?
Thanks in advance Serenarules,
tompatamcat
If your View is strongly-typed normally you’ll have an entity from the domain model attached to it like this:
System.Web.Mvc.ViewUserControl<IEnumerable<DomainModel.Entities.Page>>
But what if you need more than just an entity attached to your view? You could make a View model containing more than one entity or other necessary item like this:
public class PageViewModel
{
public SelectList PageSelectList { get; private set; }
public Page page { get; set; }
public PageViewModel(IEnumerable<Page> pageSelectListItems, Page page)
{
PageSelectList = new SelectList(pageSelectListItems, "ID", "menuTitle", page.parent);
this.page = page;
}
}
Then the model the View inherits is
System.Web.Mvc.ViewPage<mvCms.ViewModels.PageViewModel>
That way the View has access to IEnumerable<Page> and the PageSelectList value.
At least that’s how I understand it. Could be wrong about it. 
Certainly.
A lot depends on whether you are using an anemic data model (seen frequently in EntityFramework apps) or domain drive design (where business objects expose no public properties or getters), but essentially, the following reasons apply:
- Often your domain model does not meet the requirements of your views, such as when a projection, sum, count, or special grouping is required.
- You run the risk of tainting your data due to the accidental setting of a property in a view, if you are using public setters on your entities.
- Often, you may wish to dispose of your data source before sending the data to the view. Doing so using an EF model would result in the inability to traverse child records (you’ll get a disposal error).
These are the primary reasons, but there are more.
marc, if your Page object is an entity, I’d suggest not sending it at all, due to the reasons posted above.
In that example the page is a .SingleOrDefault() and the PageSelectList is just the ID and Titles of the list of pages for a DropDownList.
So it’s an entity then. You should never send an entity to a view, even if it’s embedded in a customized view model. Do this instead.
public class PageModel
{
public int Id { get; set; }
public string Title { get; set; }
public string Body { get; set; }
public static PageModel Build(Page page)
{
return new PageModel { Id = page.Id, Title = page.Title, Body = page.Body };
}
public static IEnumerable<PageModel> Build(IEnumerable<Page> pages)
{
foreach (var page in pages) yield return Build(page);
}
}
Then send it to a view like so:
return View(PageModel.Build(db.Pages.SingleOrDefault(x => x.Id == id)));
This creates a completely detached view model, which you can do anything at all to, and not worry about whether you’re maintaing a connection, or tainting your data. Or in your exact case…
public class PageViewModel
{
public SelectList PageSelectList { get; private set; }
public PageModel page { get; set; }
public PageViewModel(IEnumerable<Page> pageSelectListItems, Page page)
{
PageSelectList = new SelectList(pageSelectListItems, “ID”, “menuTitle”, page.parent);
this.page = PageModel.Build(page);
}
}
Feel free to send entities into a builder, or model constructor. Just do not expose the actual entities to the view!
Wait, does it matter that this is the view that is used to create a new Page?
No, it doesn’t matter. Never send an entity to the view. Consider the following in a view:
@{ Model.Page.Title = “foo” }
If you can do that you have a problem. What if your context isn’t disposed yet, and you call SaveChanges prior to disposal at the end of the request. You page now has a title of foo in the database!
I would separate the read model from the write model completely. But if you can’t do that, then at least transform your entities into non-entities before sending them to the view. Even if it has exactly the same structure!
Page page = db.Pages.SingleOrDefault(x => x.Id == pageId);
return View(new PageModel
{
Id = page.Id,
Title = page.Title,
Body = page.Body
});
If you were to look in one of my projects you’d see models such as:
CourseIndexDisplay
CourseCreateForm
CourseEditForm
CourseDeleteForm
All specialized for their exact task. Do you transformations in a service if you don’t want to do it in the action. Heck, I might just post a video tutorial tomorrow.