A base class to handle mapping between entities and view models

I'm working on a fairly mundane ASP.NET MVC app that allows users to do basic CRUD operations on a number of different domain objects. I'm trying to minimize duplicate code and boring, monkey code as much as possible, so I'm using AutoMapper to map types and MVC's scaffolding feature to spit out forms. I have a standard template for Index, Details, Create, Edit, Delete, and DeleteConfirmed views. Finally, I use specific view models to support these views (IndexModel, RowModel, DisplayModel, and EditModel).

I've written an abstract base class called StandardService, which works with AutoMapper to provide support for mapping from entities to view models and back again. It has generic type parameters for the entity and each type of view model.

I began a refactoring of this class based on concern that it violated SRP (and had "too many" generic parameters), but I quickly realized this just meant a lot more classes and a lot more code. Yes, the classes would be more tightly focused, and there would no doubt be greater flexibility, but it didn't seem to be flexibility I needed at this point.

So, I reverted to the single base class. I'd like feedback on whether this is a sensible/practical use of inheritance or an anti-pattern/code smell. Is there a better solution that doesn't result in an explosion of classes?

StandardService5

``
public class StandardService : ServiceBase
where TEntity : class, IEntity
where TIndexModel : IIndexModel
where TDisplayModel : IDisplayModel
where TEditorModel : IEditorModel, new()
{
public StandardService(MainDbContext dbContext) : base(dbContext) { }

public virtual TIndexModel GetIndexModel(GridSortOptions sortOptions)
{
var processedEntities = GetProcessedEntities();
var rowModels = MapProcessedEntitiesToRowModels(processedEntities);
var processedRowModels = ProcessRowModels(rowModels);
processedRowModels = SortRowModels(processedRowModels, sortOptio

I think your first instinct was right. When I see

public class StandardService : ServiceBase
    where TEntity : class, IEntity
    where TIndexModel : IIndexModel
    where TDisplayModel : IDisplayModel
    where TEditorModel : IEditorModel, new()

my nose curls at the code smell. There are far too many generics in the declaration, and a good chance it will clutter up your code later on.

If you have to have to use where with an interface, why don't you just use the interface in the class? I don't see anywhere where the classes are instantiated in your base class, and if I'm missing something, make an abstract method that returns the required class from the child class. That goes for any of the methods, use the interfaces where you can, let the sub classes take care of the rest.

Of course, I might be missing something because I haven't worked with AutoMapper before.

StackExchange Code Review Q#15695, answer score: 4