我的ASP.NET MVC应用程序是否正确构建？

Question

我一直在阅读这些教程(特别是那些使用Linq-To-Entities的教程)并且我理解了基本概念,但是有些东西给了我一些问题.

教程通常只涉及仅使用基本创建,更新和删除语句的简单模型和表单.我有点复杂,我不确定我是否正确地采用这种方式,因为当需要处理六个数据库对象的关系时,教程就会停止帮助.

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

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

不会做我想要的,因为完全实现的类没有被发布到控制器方法.我可以发布单个字段,表单集合或多个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查询,因为这个错误消息:

LINQ to Entities中仅支持无参数构造函数和初始值设定项.

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

Answer 1

_someRepositoryOrService.Add(id, classA, classB);

我想说你将你的存储库与表示层结合起来。这不应该是。您的存储库应该仅适用于实体。接下来，注意您的 Add 方法如何

公共无效添加（int id，ClassA类A，ClassB类B）

打破了关注点分离 (SoC)。它执行两项任务：

1. 将视图数据映射到实体
2. 保存到存储库

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

另请查看Jimmy Bogard（ASP.NET MVC In Action 的合著者）关于 ViewModel 的这篇优秀文章。这可能会帮助您自动映射。它还提出了一种相反的技术 - 让您的控制器与实体一起工作，而不是 ViewModel！自定义操作过滤器和模型绑定器实际上是消除不属于控制器而是视图和控制器之间的基础结构细节的例程的关键。例如，以下是我如何自动化实体检索。以下是我如何看待控制器应该做什么。

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

更新：不，存储库不应该处理表单数据，这就是我所说的“与演示耦合”的意思。是的，存储库位于控制器中，但它们不适用于表单数据。您可以（不是说您应该）使表单与“存储库数据”（即实体）一起使用，这就是大多数示例所做的，例如 NerdDinner - 但不是其他方式。这是因为一般经验法则 - 较高层可以与较低层耦合（表示与存储库和实体耦合），但低层不应该与较高层耦合（实体依赖于存储库，存储库依赖于表单模型等） ）。

第一步应该在存储库中完成，这是正确的 - 只是从 ClassX 到 EntityX 的映射不属于该步骤。这是绘图问题——基础设施。例如，请参阅有关映射的问题，但通常如果您有两层（UI 和存储库），它们不应该关心映射 - 映射器服务/帮助程序应该关心映射。除了 Jimmy 的博客之外，您还可以阅读 ASP.NET MVC In Action，或者简单地查看他们的CodeCampServer，了解他们如何使用传递给控制器​​构造函数的 IEntityMapper 接口进行映射（请注意，这是比 Jimmy Bogard 的 AutoMapper 更手动且工作量更少的方法）。

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