I am learning MVC 3 and I have not found people using some logic codes inside a property of a data model class.

They do the data model class as follows (for example):

public class Customer
{
    public int CustomerId {get;set;}
    //other properties without any logic code.
}

Is it ok to have logic codes inside a property as follows?

public class Customer
{
    private int customerId;
    public int CustomerId {
       get{return customerId;}
       set
       {
         customerId=value;
         // some logic codes go here.
       }
    }
    //other properties go here.
}

Edit 1:

This is my real scenario:

Child table data model:

namespace MvcApplication1.Models
{
    public class Choice
    {
        public int Choi开发者_JAVA百科ceId { get; set; }
        public string Description { get; set; }
        public bool IsCorrect { get; set; }
        public QuizItem QuizItem { get; set; }
    }
}

Parent table data model:

namespace MvcApplication1.Models
{
    public class QuizItem
    {
        public int QuizItemId { get; set; }
        public string Question { get; set; }

        private IEnumerable<Choice> choices;
        public IEnumerable<Choice> Choices
        {
            get { return choices; }

            set
            {
                choices = value;
                foreach (var x in choices)
                    x.QuizItem = this;
            }
        }
    }
}

Consumer:

namespace MvcApplication1.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult Index()
        {


            var data = new List<QuizItem>{
                new QuizItem
                {
                    QuizItemId = 1,
                    Question = "What color is your hair?",
                    Choices = new Choice[]{
                        new Choice{ ChoiceId=1, Description="Black.", IsCorrect=true},
                        new Choice{ ChoiceId=2, Description="Red.", IsCorrect=false},
                        new Choice{ ChoiceId=3, Description="Yellow.", IsCorrect=false}
                    }
                },
                new QuizItem
                {
                    QuizItemId = 2,
                    Question = "What color is your noze?",
                    Choices = new Choice[]{
                        new Choice{ChoiceId=1, Description="Pink.", IsCorrect=false},
                        new Choice{ChoiceId=2, Description="Maroon.", IsCorrect=true},
                        new Choice{ChoiceId=3, Description="Navy Blue.", IsCorrect=false}
                    }
                }
            };


            return View(data);
        }

    }
}

This calls for a method. Two reasons why:

• I don't recommend setters for Collections
  • Property Usage Guidelines - Setting a property for each item in collection every time property is set is expensive and should not be in a property. A method is preferred instead.
• Code (that you have in your case) in setter causes enough side-effects to disqualify use of property
  • Setters for collection type properties - A discussion on StackOverflow regarding setters for collections.

I suggest following:

public class QuizItem
{
    public int QuizItemId { get; set; }
    public string Question { get; set; }

    private IEnumerable<Choice> choices;
    public IEnumerable<Choice> Choices
    {
        get { return choices; }
    }

    public void SetChoices(IEnumerable<Choice> choices)
    {
        foreach (var x in choices)
            x.QuizItem = this;

        this.choices = choices;                
    }
}

I think this logic you should implement in controller. However I always define POCO classes in my model and use ViewModel to implement such simple logic.

This is more of a realm of philosophical approach. As such it is up to a debate.

Today by far the most prevalent approach is to use strict layered approach of separation of concerns where "model" objects are only responsible for containing data and if you want to apply any sort of business logic on top of that, you need to implement that on a separate "business logic" layer, which handles application of such concerns as validation/vewrification of the integrity of data, mutation of data according to a business processes, etc.

Another approach is to use model layer to actually model (as in verb) the business of the target domain. In this case, the model acts as a direct definition of the business rules and should just as rich as rules of the business require it to be. (this approach has been taken to extreme by Naked Objects, that basically keeps data structures as well as business logic in the model and generates ORM, controller logic and views from the same model)

Generally the question of "how smart can/should be my model objects" is one to ask from the frameworks you use. Some frameworks simply don't care either way (ASP.NET MVC), others want you to never worry about coding this stuff, as long as you provide enough metadata so that they can do their job for you (NHibernate, Entity Framework). Others yet encourage you to express all your business rules and logic in the domain object model (e.g. Naked Objects)

In my opinion, a data model should be doing logic related to data (value) as in "is this value a valid data to...?". Also when doing hidden logic like in this case "attaching a parent", naming the method to just "set" is also wrong.

A sample of a more complex data model: https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-a-more-complex-data-model-for-an-asp-net-mvc-application