Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For my models for a certain section I thought it would be better to have a base class model for both "view" and "edit" models, like so:

public abstract class Setting
{
    [Required]
    public int SettingId { get; set; }

    public string Name { get; set; }

    [Required]
    [MaxLength(255)]
    public string Value { get; set; }
    public string ModifiedBy { get; set; }
    public DateTime ModifiedDt { get; set; }
}

public class ViewSetting : Setting
{
}

public class EditSetting : Setting
{
}

So in my Service or Views I use the appropriate ViewSetting or EditSetting. Right now I don't have anything that would be different - but should I follow a pattern like this to maintain a separation of concerns here? Or should I just stick to using one Setting class? (as an aside, I'm using Entity Frameworks but in my Service layer is where I convert to/from the models for the ORM)

share|improve this question

closed as off-topic by Malachi, Ethan Bierlein, Mast, Mat's Mug, Quill Jun 19 '15 at 17:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." – Malachi, Ethan Bierlein, Mast, Mat's Mug, Quill
If this question can be reworded to fit the rules in the help center, please edit the question.

    
I might consider composition over inheritance in this case. Of course that's probably a preference thing. – dreza May 15 '13 at 7:05
    
Meaning you would include Setting as an object in both ViewSetting and EditSetting? – Cody May 16 '13 at 0:17
    
Yes that would be one alternative to using the inheritance model – dreza May 16 '13 at 1:18
1  
You mentioned "Right now I don't have anything that would be different". So you don't need it. If you need it, you can always add it later. Try to go with the simplest solution that possibly work. I would simply use a one Setting class as you mentioned. – Raj May 16 '13 at 8:36

The Model wouldn't change regardless of whether you were viewing it or editing the records in the given model.


Let's go ahead and create a view and edit model from the information you have given us, it will look like this

Note: this doesn't work, it is here to make a point.

public abstract class Setting
{
    [Required]
    public int SettingId { get; set; }

    public string Name { get; set; }

    [Required]
    [MaxLength(255)]
    public string Value { get; set; }
    public string ModifiedBy { get; set; }
    public DateTime ModifiedDt { get; set; }
}

public class ViewSetting : Setting
{
    public int SettingId { get; }
    public string Name { get; }
    public string Value { get; }
    public string ModifiedBy { get; }
    public DateTime ModifiedDt { get; }
}

public class EditSetting : Setting
{
    [Required]
    public int SettingId { set; }

    public string Name { set; }

    [Required]
    [MaxLength(255)]
    public string Value { set; }
    public string ModifiedBy { set; }
    public DateTime ModifiedDt { set; }
}

and then you don't want to go setting the ID Field because that would change more than the properties of the data, it would be changing indexing in your database, so we would take that out too. And if you were going to edit the Record you should also make the ModifiedBy and ModifiedDt required.

Also, because if you implement the Abstract class you implement everything anyway, it really doesn't make sense to create an abstract class, so I make them all regular classes and you can see what is really going on here.

public class Setting
{
    [Required]
    public int SettingId { get; set; }

    public string Name { get; set; }

    [Required]
    [MaxLength(255)]
    public string Value { get; set; }
    public string ModifiedBy { get; set; }
    public DateTime ModifiedDt { get; set; }
}

public class ViewSetting 
{
    public int SettingId { get; }
    public string Name { get; }
    public string Value { get; }
    public string ModifiedBy { get; }
    public DateTime ModifiedDt { get; }
}

public class EditSetting 
{
    public string Name { set; }

    [Required]
    [MaxLength(255)]
    public string Value { set; }
    [Required]
    public string ModifiedBy { set; }
    [Required]
    public DateTime ModifiedDt { set; }
}

you wouldn't really make separate models for editing and viewing. it isn't needed.

The properties do the getting (get = view) and setting (set = edit). so there isn't really a reason to make two separate models, one for getting and one for setting, when one class/model can do it all

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.