Models in .NET: separate settings 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)
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