0

This is probably very basic question but I can't find straight answer to it, I was thinking about it for a while and still didn't figure out what is best practice?

In parent - child relationship, e.g. Department / Employee should I have actions like:

DepartmentController -> addEmpoyee(deptId) 
DepartmentController -> editEmpoyee(empId)
DepartmentController -> employees(deptId)

Or rather create separate controller for Employee operations? EmployeeController -> add(deptId) EmployeeController -> edit(empId) EmployeeController -> list(deptId)

Second approach makes sense to me but the first seems to be logical as well as employees are child entities of dept...

chridam
  • 100,957
  • 23
  • 236
  • 235
GrumpyHat
  • 281
  • 2
  • 15

1 Answers1

1

I would make a DepartmentCrudController gathering those methods (index, show, create, delete, new, edit).

Indeed, CRUD is ONE responsibility in itself, so does not break Single Responsibility Principle.

However, associated commands called by controller (take a look at CQRS for instance), if contain some business logic (task-driven UI), should themselves be separated in order to be less sensitive to change, increasing the flexibility of your application.

But for a simple CRUD, one service layer class is enough.

Your controller should be a simple humble object delegating to your use cases (services layer), meaning without ANY business logic at all.

Mik378
  • 21,881
  • 15
  • 82
  • 180
  • thanks so I guess I will use separate controller - if I understand this correctly. This makes sense to me although sometimes it looks easier to just throw all the related logic to parent controller... – GrumpyHat Jun 16 '14 at 15:09
  • @GrumpyHat No I meant the reverse: Keep just one controller. CRUD represents one responsibility by itself, especially in the controller since it aims to be a simple humble object. – Mik378 Jun 16 '14 at 15:17
  • Right, but in that case the controller may grow quite big, as I will have add,edit,delete,search(index),view for dept and again for employee as they are using different forms (this is a web app). On top of that I will most likely have more custom methods for both parent and child entities... – GrumpyHat Jun 16 '14 at 15:25
  • Custom methods should be part of another controller. I worked today on a similar CRUD controller, and it takes about 3 lines maximum by methods. (since humble object => only delegation to model). http://stackoverflow.com/questions/5324049/what-is-the-humble-object-pattern-and-when-is-it-useful – Mik378 Jun 16 '14 at 15:33
  • I think I kinda have it this way actually. I have a generic controller which handles common tasks view, add etc. All other controllers inherit from the generic one. All non standard logic is in separate controllers. so I probably should have separate controllers for dept and employee BUT only have custom logic in there? Or am I still missing the point? – GrumpyHat Jun 16 '14 at 15:40
  • 1
    You want to have `DepartmentCrudController` (CRUD for departement), `EmployeeCrudController` (CRUD for employee), and common methods on the parent one, let's call it, `BaseCrudController`. This BaseCrudController might be itself inherits from `BaseController` that is the root of all. All methods that aren't common to both `DepartmentCrudController` and `EmployeeCrudController` AND having nothing to do with CRUD, should be part of a complete other controller or better just another model. – Mik378 Jun 16 '14 at 15:57