ASP.NET MVC-服务层<->控制器

Question

假设您正在实现自己的Stackoverflow版本（再次，是）

您拥有提供这样所有必需功能的服务：

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

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

这似乎很简单，我通常认为这是一个好主意。我在这里唯一不喜欢的是客户端代码（ASP.NET MVC控制器）直接访问 Question沙 Answers。假装我们与发布问题和答案有关。最好将此逻辑集中在服务层上的“单个位置”。如果您的客户端代码可以访问 QuestionS，有一天有人会决定在您的一个控制器中添加“一点点逻辑”，这基本上是坏主意。

我正在考虑定义许多DTO，这些DOS将成为服务接口的一部分，因此客户端代码只能与包含“恰好适量详细信息”的这些DTO一起使用。

假设您的问题实体是这样定义的：

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

发布问题时，请求仅应包含 Title, Text 和 Poster. 。所以，我将定义一个 PostQuestionDTO:

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

当有人打开页面检查问题时，还有更多细节 Posted 和 Edited:

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

等等。这是一个好习惯还是您认为它过度工程？这里有什么常见方法？

Answer 1

最近，我使用了许多Ninight和Automapper实现了您所说的内容。我的逻辑结构就是这样：

    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.

我认为这根本不会过度杀伤 - 是的，写作需要更长的时间，但是自动驾驶员基本上为您删除了大部分的驴子工作。

我的一个同事非常热衷于控制控制，这显然解决了这个问题……尽管我还没有完全卖出它:)