ASP.NET MVC - Service Layer <-> Contrôleurs

Question

Disons que vous implémentez votre propre version de stackoverflow (encore une fois, oui)

Vous avez un service qui offre toutes les fonctionnalités requises comme ceci:

class Question { ... } // EF entity
class Answer { ... } // EF entity

interface IStackoverflowService
{
    void PostQuestion(Question question);
    void PostAnswer(Answer answer);
    void UpdateQuestion(Question question);
    ...
}

Cela semble être assez simple et je crois qu'il est généralement une bonne idée. La seule chose que je ne aime pas ici est que le code client (contrôleurs ASP.NET MVC) a un accès direct à Questions et Answers. Faire semblant que nous avons des BL difficiles liées à des questions et réponses messages. Il est bon d'avoir cette logique concentrée dans un « lieu unique » - sur une couche de service. Dans le cas où votre code client a accès à Questions, il est possible que quelqu'un un jour décidera d'ajouter « un peu de logique » à un de vos contrôleurs qui est fondamentalement mauvaise idée.

Je pense à définir un certain nombre de DTO qui sera la partie de l'interface de service, de sorte que le code client ne sera en mesure de travailler avec ces DTO qui contiennent « juste la bonne quantité de détails ».

Disons que votre entité question est définie comme ceci:

interface Question
{
    int Id { get; set; }
    User Poster { get; set; }
    DateTime Posted { get; set; }
    DateTime? Edited { get; set; }
    string Title { get; set; }
    string Text { get; set; }
    IQueryable<Answer> Answers { get; set; }
    ...
}

Lors de l'affichage de la question, la demande ne doit contenir que Title, Text et Poster. Alors, je vais définir un PostQuestionDTO:

class PostQuestionDTO
{
    User Poster { get; set; }
    string Title { get; set; }
    string Text { get; set; }
}

Quand quelqu'un ouvre la page pour vérifier la question, il y a un peu plus de détails comme Posted et Edited:

class QuestionDetailsDTO
{
    User Poster { get; set; }
    string Title { get; set; }
    string Text { get; set; }
    DateTime Posted { get; set; }
    DateTime? Edited { get; set; }
}

Et ainsi de suite. Est-ce une bonne pratique ou pensez-vous qu'il est overengineering? Quelles sont les approches communes ici?

Answer 1

Je l'ai récemment mis en œuvre à peu près exactement ce que vous parlez, en utilisant beaucoup de Ninject et AutoMapper. Ma structure logique est comme ceci:

    MyCompany.Data // Data layer namespace containing EF EDMX file / Codefirst / ADO.Net, whatever you want.
    class User { } // EF Entity

MyCompany.Business // Business layer namespace containing business level factory interfaces and classes that expose their own business objects (some are directly mapped to the DB, most are not). All members expose POCO objects

class NewUser { } // POCO class RegisteredUser { } // POCO interface IAccountFactory {
    void AddUser(NewUser user);
    RegisteredUser GetUser(int id); } // factory interface class AccountFactory : IAccountFactory // Service provider

MyCompany.MVC // Presentation layer containing controllers and views. Controllers expose POCO objects from the business layer to the Views.

Je ne pense pas qu'il soit exagéré du tout -. Oui, il faut un peu plus de temps pour écrire, mais AutoMapper supprime essentiellement la plupart des travaux d'âne pour vous

Un de mes collègues est très vif sur l'inversion de contrôle, ce qui permet de résoudre ce problème apparemment ... mais je ne suis pas complètement vendu sur encore:)