2
\$\begingroup\$

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)

\$\endgroup\$
  • \$\begingroup\$ I might consider composition over inheritance in this case. Of course that's probably a preference thing. \$\endgroup\$ – dreza May 15 '13 at 7:05
  • \$\begingroup\$ Meaning you would include Setting as an object in both ViewSetting and EditSetting? \$\endgroup\$ – Cody May 16 '13 at 0:17
  • \$\begingroup\$ Yes that would be one alternative to using the inheritance model \$\endgroup\$ – dreza May 16 '13 at 1:18
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Raj May 16 '13 at 8:36
2
\$\begingroup\$

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

\$\endgroup\$

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