MVC3 Controller per Entiry or Controller per group of entities?

Question

May be a stoopid question:

I have a number of reference tables in an application database, which I want to be updated from my MVC3 site.

I can create a "ReferenceController" which has CRUD methods for each of these tables

or

I can create a "EntityController" which has CRUD methods JUST for this one reference table (entity).

Not sure if there is a sensible pattern to follow for this?

EDIT:

If I do create a controller per Aggregate, then how do you name the methods on the controller?

e.g.
ReferenceController.CreateBusiness();
MyApplication/Reference/CreateBusiness
?

I have multiple, totally unrelated "reference" entities, would that mean a controller with a very large number of methods in there? e.g. List, Create, Read, Update, Delete + confirmations?

Can you make controller methods Generic and have Create(T ...) ?

I've looked at repository/service patterns, so I could have a "ReferenceRepository + ReferenceService + ReferenceController" but then equally I could have "EntityRepository etc..." — BlueChippy, Jun 28 '12 at 10:20

Mohayemin · Accepted Answer · 2013-09-29T03:30:32.613

4

I would do something like this:

A Generic Crud Repository like:

class CrudRepo<TEntity> where T : class{
  void All();
  void Add(TEntity entity);
  void Edit(TEntity entity);
  void Delete(TEntity entity);
}

Then A generic Crud Controller like

class CrudController<TEntity> where T : class{
    CrudRepository<TEntity> Repository;

    [HttpPost]
    ActionResult Add(TEntity entity){
      Repository.Add(entity);
    }

    // Similer for other actions
}

And for specific type of entities, just extend CrudController like:

class StudentController : CrudController<Student>

Edit 1:

If you have really TOOOO many entities, there are ways to eliminate the need of inheriting the CrudController for each entity. You may want to write your custom ControllerFactory for that.

edited Sep 29 '13 at 03:30

answered Jul 03 '12 at 06:18

Mohayemin

3,841
4
25
54

This is an excellent way to go...since my entities are non-related, a single generic repository would be great and simple to implement. (Bounty coming...just waiting for the 20 hours limit) – BlueChippy Jul 03 '12 at 08:16
@BlueChippy- Dude just one more thing . Please add a Middle business Service layer between the controller and the repository , since the code concerns are very separated and if in case you have to change the MVC 3 to something else then in that case just the web layer needs to be change rather than recoding it from the scratch. – bhuvin Jul 03 '12 at 13:08
@Mohayemin looking to implement this now and no problem with my actual CRUD(L) methods, but unsure what to do about my service layer: e.g. I need to Update, so I Read an entity, pass to service, pass to controller (as ViewModel), pass back updated ViewModel to controller, back to Service ... which does what? Does it user the Repository Read to get the entity, then pass that back through the Update method? – BlueChippy Jul 09 '12 at 12:16

score 3 · Answer 2 · edited May 23 '17 at 11:43

3

You should have a repository per aggregate root. Same stands for controllers.

edited May 23 '17 at 11:43

Community

1
1

answered Jun 28 '12 at 10:24

Darin Dimitrov

1,023,142
271
3,287
2,928

...and is it best practice, even in a simple app, to go repository/service/controller...or just controller? – BlueChippy Jun 28 '12 at 10:45
1

Sorry, next related stoopidity: How do I name my methods. e.g. Create becomes CreateBusinessReference, or add routing to handle /MyApp/Reference/Business/Create ? – BlueChippy Jun 28 '12 at 10:57

score 1 · Answer 3 · answered Jul 03 '12 at 04:24

Two things come to mind:

Use something like WEB API so you don't have to recreate boilerplate code for every entity.
Only create CRUD-like controllers for top-level entities, i.e. what's the point of creating a controller for something that isn't changeable to any clients.

MVC3 Controller per Entiry or Controller per group of entities?

3 Answers3