Mieux d'avoir d'énormes Contrôleurs, ou de nombreux contrôleurs MVC?

Question

Nous construisons une assez grande application RH dans ASP.NET MVC, et jusqu'à nos contrôleurs sont en train de devenir très volumineux. Par exemple, nous avons un Employé de contrôleur, et tous les employés de vues sont inclus (informations Personnelles, l'employé-e déductions, personnes à charge, etc). Chacun de ces points de vue peut avoir plusieurs actions ou des sous-vues (par exemple, CRUD). Chaque action est relativement faible, mais le contrôleur peut avoir des dizaines de fonctions.

Existe-il des pratiques exemplaires pour le fractionnement des contrôleurs? Au lieu d'avoir un Employé contrôleur avec des dizaines de points de vue, serait-il mieux avoir un contrôleur pour chaque sous-type (c'est à dire EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController)?

Et enfin, est-il encore de l'importance?

Mise À Jour Des Éclaircissements

Mon premier souci était avec CRUD actions. Par exemple, considérons Créer et de Supprimer des ...

Actions en cours dans EmployeeController:

  CreateEmployee()
  DeleteEmployee()
  CreateEmployeeDeduction()
  DeleteEmployeeDeduction()
  CreateDependent()
  DeleteDependent()
  etc.

Si les contrôleurs de split:

  EmployeeController
    Create()
    Delete()
  EmployeeDeductionController
    Create()
    Delete()
  EmployeeDependentController
    Create()
    Delete()
  EmployeeBenefitController
    Create()
    Delete()
  etc.

Dans le 1er scénario, nos ~100 écrans obtenez divisé en 8 à 10 grandes contrôleurs. Dans la deuxième, j'aurais probablement ~50 contrôleurs.

Answer 1

Partielle classes vous permettent de diffuser votre classe dans plusieurs fichiers. De cette façon, vous pouvez regrouper les domaines pertinents de votre contrôleur dans des fichiers séparés, et pourtant ils vont tous continuer à faire partie de la même contrôleur. par exemple

EmployeeDeductionController.cs

public partial class EmployeeController
{
    public ActionResult Deduct()
    {
    }
    // etc
}

EmployeeBenefitController.cs

public partial class EmployeeController
{
    public ActionResult GiveBenefit()
    {
    }
    // etc
}

Answer 2

À mon humble avis, si vous souhaitez conserver le code dans vos contrôleurs, alors il n'importe pas vraiment.

La plupart de votre code devrait être le cas dans une entreprise de la couche quelque part à droite? Si c'est le cas, alors tout ce que vous êtes vraiment en train de faire dans votre contrôleur est le renvoi de données à l'affichage. Comme il se doit.

Pas vraiment sûr si je suis un fan de la séparant les contrôleurs en sous-types. Alors que vous devriez maintenir la séparation des préoccupations, je pense que les sous-types est aller un peu trop loin.

Vous pouvez prendre un coup d'oeil à ce post pour voir si ça aide. Même À La Vue Des Chemins Différents

Que peut être une meilleure solution que d'utiliser un sous-type d'approche que vous avez suggéré.

Answer 3

Je ne voudrais pas avoir 50 contrôleurs. Maintenant j'ai 16 dans mon application et qui se sent ok. Si vous avez 50 contrôleurs, vous aurez également 50 toplevel dossiers pour les vues. Ça va être dur de trouver de la vue et le contrôleur, vous devez travailler sur. Comme d'autres l'ont mentionné les actions sont généralement de courte et il n'est pas mauvais d'avoir un couple d'entre eux dans votre contrôleur.

J'ai essayé d'avoir 1 contrôleur de système. Je définir un système de la partie en prenant mon schéma de base de données et de tracer une ligne autour de tables qui vont ensemble.

Answer 4

Pourquoi ne pas les regrouper?

Avoir une structure comme celle-ci,

employee/payroll/
    employee/payroll/giveraise
    employee/payroll/manage401k

employee/general/
    employee/general/address
    employee/general/emergencycontact

Maintenant vous pouvez avoir de la masse salariale contrôleur de manutention liées à la paie des actions et un contrôleur général qui gère régulièrement des détails d'un employé.

Answer 5

Les contrôleurs sont destinés à être des conteneurs pour les actions en vertu d'un contexte. I. E. un client contrôleur aurait actions relatives au contrôle des clients. C'est particulièrement adapté aux CRUD. Je voudrais aller avec moins de plus gros, des contrôleurs pour cette raison. Cela dit, il est vraiment à vous de même que l'application de l'architecte de choisir la méthode qui convient le mieux à votre code et juste parce qu'il est plus courant de le faire d'une manière ne signifie pas que vous devez.

Si vous avez de grandes quantités de code, je vous suggère de regarder dans ASP.NET MVC domaines. Vous pouvez trouver d'excellents posts à ce sujet Ici dans Scott Gu blog et Ici, dans Steve Sanderson du blog. Si vous avez plusieurs contrôleurs, il pourrait être approprié pour vous.

Juste eu une pensée après re-lecture de votre post, je pense que votre exemple n'est pas près à le niveau de complication que vous avez dans votre code. Peut-être qu'il pourrait aider si vous avez posté une situation où vous n'êtes pas certain de savoir si elle était ou non une bonne idée de diviser votre contrôleur qui est plus précis (et moins CRUDDY, parce que CRUD est assez simple).