asp.net-mvc - 我的 ASP.NET MVC 应用程序结构是否正确？

Question

我一直在阅读教程(特别是使用 Linq-To-Entities 的教程)并且我了解基本概念，但是有些事情给我带来了问题。

这些教程通常只涉及简单的模型和表单，它们只使用基本的创建、更新和删除语句。我的稍微复杂一些，我不确定我是否以正确的方式进行处理，因为当需要处理六个数据库对象的关系时，教程不再提供帮助。

对于 post 方法，执行 CRUD 操作的常用方式

entities.AddToTableSet(myClass);
entities.SaveChanges();

不会做我想做的事，因为完全实现的类没有发布到 Controller 方法。我可以发布单个字段、表单集合或多个 DTO 对象，然后调用服务或存储库上的方法来获取我从表单发布中收到的信息，以及它需要查询或创建自身的信息，然后从所有这些，创建我可以保存的数据库对象。

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Add(int id, [Bind(Exclude = "Id")] ClassA classA,
                        [Bind(Exclude = "Id")]ClassB classB)
{
   // Validation occurs here

   if(!ModelState.IsValid)
      return View();

   try
   {
      _someRepositoryOrService.Add(id, classA, classB);
      return RedirectToAction("Index", new { id = id });
   }
   catch(Exception ex)
   {
      // Logging and exception handling occurs here
   }
}


public void Add(int id, ClassA classA, ClassB classB)
{
    EntityA eA = new EntityA
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    EntityB eB = new EntityB
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    _entity.AddToEntityASet(eA);
    _entity.AddToEntityBSet(eB);
    _entity.SaveChanges();
}

我是在正确处理这个问题，还是在混淆框架？我从来没有直接使用实体对象，每当我查询一个实体对象时，我都会将我需要的信息放在 DTO 中，并以此为基础。创作也是如此。这是允许的，还是我避免使用实体直接违背了使用框架的目的？

编辑:我也担心这种方法，因为它需要空构造函数来正确执行 LINQ 查询，因为此错误消息:

Only parameterless constructors and initializers are supported in LINQ to Entities.

这没什么大不了的，因为我很少需要构造函数中的逻辑，但是没有构造函数而只有公共(public)属性是一个问题吗？

Answer 1

_someRepositoryOrService.Add(id, classA, classB);

我会说你将你的存储库与表示层结合起来。这不应该。您的存储库应仅与实体一起使用。接下来，注意您的 Add 方法

public void Add(int id, ClassA classA, ClassB classB)

打破关注点分离 (SoC)。它执行两个任务:

将 View 数据映射到实体

保存到存储库

显然第一步应该在表示层完成。考虑为此使用模型绑定(bind)器。它还可以帮助您解决构造函数问题，因为您的模型绑定(bind)器可以了解构造要求。

还要检查这个优秀的 post Jimmy Bogard(ASP.NET MVC In Action 的合著者)关于 ViewModels 的文章。这可能会帮助您自动映射。它还提出了一种相反的技术——让你的 Controller 与实体一起工作，而不是 ViewModels!自定义 Action 过滤器和模型绑定(bind)器确实是消除不属于 Controller 的例程的关键，而是 View 和 Controller 之间的基础设施细节。例如， here是我如何自动化实体检索。 Here这就是我如何看待 Controller 应该做什么。

这里的目标是让 Controller 满足于管理业务逻辑，将所有不属于您的业务的技术细节放在一边。您在这个问题中谈论的是技术限制，您让它们泄漏到您的代码中。但是您可以使用 MVC 工具将基础架构级别迁移到它们。

更新:不，存储库不应该处理表单数据，这就是我所说的“与演示相结合”的意思。是的，存储库在 Controller 中，但它们不适用于表单数据。您可以(不是您应该)使表单与“存储库数据”(即实体)一起使用，这就是大多数示例所做的，例如NerdDinner - 但不是相反。这是因为一般的经验法则 - 较高层可以与较低层耦合(表示与存储库和实体耦合)，但决不应该将低层耦合到较高层(实体依赖于存储库，存储库依赖于表单模型等)。

第一步应该在存储库中完成，没错——除了从 ClassX 到 EntityX 的映射不属于该步骤。这是映射问题 - 基础设施。参见示例 this关于映射的问题，但通常如果您有两个层(UI 和存储库)，他们不应该关心映射 - 映射器服务/助手应该。除了 Jimmy 的博客，您还可以阅读 ASP.NET MVC In Action 或直接查看他们的 CodeCampServer了解他们如何使用传递给 Controller ​​构造函数的 IEntityMapper 接口(interface)进行映射(请注意，这比 Jimmy Bogard 的 AutoMapper 更加手动且工作量更少)。

还有一件事。阅读领域驱动设计，查找文章，从中学习，但您不必遵循所有内容。这些是指导方针，而不是严格的解决方案。看看你的项目能不能处理，看看你能不能处理，等等。尝试应用这些技术，因为它们通常是进行开发的优秀和认可的方法，但不要盲目地接受它们 - 沿途学习比应用你不理解的东西要好。