Question

我们正在开发的ASP NET解决方案由多个层组成，用户界面是使用asp net mvc 2 web表单视图引擎开发的，它广泛使用模板编辑器和数据注释（最近我们将其升级到asp net mvc 3）。例如，我们在RegistrationController中有Create动作：

        [HttpPost]
        public ActionResult Create(PersonViewModel person)
        {

            try
            {
                if (!ModelState.IsValid)
                {
                    return View(person);
                }
                else
                {
             var personInterface = BusinessRegister.PersonHandler.Save(person);
                    return View("Edit", personInterface);
                }

            }
            catch {

            }
        }

因此，我们有PersonViewModel，它是简单的数据传输对象，将从浏览器传递的信息连接到控制器动作。此外，它调用PersonHandler.Save（在此调用之后保留WCF服务，负责将传输的对象序列化为PersonEntity（LLBL对象）。

问题发生是因为WCF需要合同所以它不知道如何处理PersonViewModel（或者更好地如何序列化它），因此首席架构师给出了一个建议，将引用直接放在ORM实体所在的程序集上并进行更改控制器签名。所以现在我们的控制器看起来像

[HttpPost]       
 public ActionResult Create(PersonEntity person)
        {
….

我向你寻求帮助 - 这样做是否正确 - 将ORM实体置于mvc框架的默认模型绑定器之后？我不确定这是最好的建模实践 - 它不是viewModel，所以我们以后可以使用某种映射到PersonEntity？或者，更好的是，如何避免在这里紧密耦合（这是显而易见的）。提前谢谢。

Answer 1

使用ORM实体类作为控制器动作中的参数，从应用程序的顶层到底层，直接射出硬依赖的箭头。

我认为走这条路线会对你在应用程序中进行更改的能力产生非常不利的影响。

现在，您必须使用发布POST的HTML表单协调实体中的任何更改。这非常糟糕，面对我见过的关于MVC的每一个最佳实践建议。

Answer 2

一个价格的3个答案：

自动播放器（automapper.codeplex.com）
使用它
喜欢它＆lt; 3

Answer 3

我认为这取决于您的业务逻辑和实际需求。为简单起见，为什么不直接使用Domain Entity？我没有看到任何使用ViewModel或View Object等的理由。如果仅作为数据容器工作，域实体通常不需要进行测试。如果您有丰富的域实体，我认为您应该创建一个ViewModel来执行此操作。如果你需要考虑性能，如加载一个大的列表或需要跨越不同的表获取一些信息，我建议你使用View Object并手动创建sql供ORM使用。

我们应该将LLBL ORM实体对象作为参数放入控制器动作方法中

3 个答案: