views:

100

answers:

3

How do data frameworks such as Linq 2 SQL, ADO.Net Data Entities and DataSets relate to the "Model" as defined by .Net MVC.

The reason I ask is I'm trying to learn the ins and outs of the .Net framework without relying on many of the tools that make it easy and hide the workings from you.

The "model" I'm building in my exploratory app is simply PostgreSQL commands to update the database. I'm purposefully not using a data "framework".

I'm finding that much of the functionality that comes as part of the .Net MVC framework isn't working for me. Stuff like UpdateModel() and anything related to ModelState doesn't seem to acknowledge what's going on.

Is much of that functionality tied to using Linq 2 SQL or ADO.Net Data Entities? If so, that's fine, I just don't quite understand the relationship yet.

+2  A: 

Unlike Views and Controllers, there's not really any restrictions on what the Model is in an ASP.NET MVC app. It just enables you to model the data in your app and clearly and safely express your intent without having to resort to using dictionaries such as ViewData to pass data around.

In terms of the model-related functionality, I believe (not 100% sure) that it is based on having public properties on your model objects. If you call UpdateModel or its relatives, it will set public properties on the model object based on the form data etc. All it does it set properties on that in-memory object if it finds appropriate ones that match form inputs etc. You still need to include the logic to actually persist that to a database or whatever else it is you want to do.

Hope this points you in the right direction at least.

Jon
Well, this is good news and bad news. Good in that what you're saying is consistent with my understanding of the goals of MVC; bad in that now I need to look for another reason why UpdateModel isn't working.
andrewheins
+1  A: 

Figured it out. For the sake of completeness...

Ok, so there is a "minimum standard" for models in .Net.

This is NOT accepted as a model:

namespace MVCApplication.Models
{
    public class Person
    {
        public int ID;
        public string Name;
        public string Title;    
        public string Description;      
        public string Phone;     
        public string Address;      
        public string Country;              

        public Person()
        {

        }

    }
}

This IS accepted as a model:

namespace MVCApplication.Models
{
    public class Person
    {
        private int _ID;
        private string _Name;
        ...

        public Person() {}

        public int ID { get{ return _ID } set{ this._ID = value } }
        public int Name { get{ return _Name } set{ this._Name = value } }
        ...
    }
}

I can't say I completely understand why, but at least now I know.

andrewheins
If you look into the MVC source code (specifically the DefaultModelBinger) you'll see that it performs bindings on Properties using reflection. Also, try using the syntax `public int ID { get; set; }`, it's a lot less messy.
Alastair Pitts
+1  A: 

Basically your "Model" object needs to have a parameterless constructor and public get/set properties for it to function easily with the DefaultModelBinder.

Tip: I believe that if you fail to define a parameterless constructor, an empty one is inferred for you (just so you don't freak out: "ahh! i don't hav a parameterless constructor").

So this would generally work fine:

public class Customer
{
    public int ID { get; set; }
    public string Name { get; set; }
    public string Number { get; set; }
    public string Email { get; set; }
}
cottsak
@andrewheins: automatic setters and getters make properties a little simpler to use if you don't need custom setter and getter logic. The example above uses the auto properties as opposed to your answer where you needed to wire them up to the `private` fields.
cottsak
It seemed like a lot of overhead for such a simple object. Thanks for the clarification.
andrewheins