ASP.NET MVC - Service Layer <-> Controller

Question

Diciamo che si sta implementando la propria versione di StackOverflow (ancora una volta, sì)

Si dispone di un servizio che fornisce tutte le funzionalità necessarie in questo modo:

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

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

Questo sembra essere piuttosto semplice e, in generale credo che sia una buona idea. L'unica cosa che non mi piace è che il codice cliente (controllori ASP.NET MVC) ha accesso diretto al Questions e Answers. Fingere abbiamo qualche BL dura in relazione con le domande e le risposte pubblicazione. E 'una buona idea avere questa logica concentrata in un "posto unico" - su un livello di servizio. Nel caso in cui il vostro codice cliente ha accesso a Questions, è possibile che un giorno qualcuno deciderà di aggiungere "solo un po 'di logica" per uno dei controller che è fondamentalmente cattiva idea.

Sto pensando di definire una serie di DTOs che saranno la parte di interfaccia del servizio, in modo che il codice client sarà in grado di lavorare con queste DTOs che contengono "la giusta quantità di dettagli".

Diciamo vostra entità domanda è definita in questo modo:

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; }
    ...
}

Quando la pubblicazione della domanda, la richiesta deve contenere solo Title, Text e Poster. Così, mi definisco un PostQuestionDTO:

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

Quando qualcuno apre la pagina per controllare la domanda, c'è un po 'più dettagli come Posted e Edited:

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

E così via. E 'una pratica bene o pensi che è overengineering? Quali sono i comuni si avvicina qui?

Answer 1

Recentemente ho realizzato più o meno esattamente quello che stai parlando, con un sacco di Ninject e automapper. La mia struttura logica è come questo:

    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.

Io non credo che sia eccessivo a tutti -. Sì, ci vuole un po 'più tempo per scrivere, ma automapper elimina praticamente la maggior parte del lavoro asino per voi

Un mio collega è molto appassionato di Inversion of Control, che risolve questo problema a quanto pare ... anche se non sono completamente venduto su di esso ancora:)