如何加速我的MVC4应用程序开发？

Question

我知道这听起来很奇怪 - 让我解释一下：

我目前正在开发一个标准的带数据库的Web应用程序。我选择使用IoC框架（Ninject），Entity Code First，Bootstrap和其他相关技术。我已经用UML转录了数据库模型，现在正在逐步实现它。通常是按照以下步骤进行：

1. 选择要实现的功能。
2. 检查需要哪些数据库表。
3. 创建适当的POCO类。
4. 使用迁移工具生成新的数据库。
5. 创建所有所需的CRUD方法以满足该功能。 （我知道我应该创建单元测试，但时间真的不够:/）

首先的问题是 - 你是否认为上述内容“正常”？也许我错过了一些可以加快开发速度的东西？或者我应该添加更多步骤 - 例如提前捕获更多错误？

现在下一步是创建视图，所以我会这样做：

1. 在适当的控制器中创建ViewMethod。
2. 基于一个或多个POCO数据库类创建ViewModel。
3. 为我的新ViewModel创建编辑器模板。
4. 在控制器中创建功能逻辑。

上述方法的问题是：

1. I often have to create nearly a duplicate of POCO entity, then - during save procedure, I need to convert it back to the appropriate POCO entities, usually like this:

   PocoEntity1 pocoEntity1 = new ()
   {
       UserName = ViewModel.UserName,
       UserPicture  = ViewModel.UserPicture
       (and so on)
   } 
   

以上操作相当费时且容易出错 - 另一方面，如果我直接使用POCO，我将不得不添加很多属性，如：

[Required]
[StringLength(128)]
[DisplayNameLocalizer("FirstName", typeof(TranslationStrings))]

这并不是推荐的做法（有时我想为某些属性设置不同的名称，具体取决于视图）。

问题在于 - 是否有什么“中间”方式？例如，直接将ViewModelEntity转换为POCO实体的方法会非常有帮助。我是否可以做些什么来加速，或者我现在的做法是否正确？

- user2384366

Answer 1

我相信有人会建议使用Entity Framework内置控制器脚手架，但是我的经验是，在构建真实世界的MVC应用程序时，内置脚手架适用于业余项目和POC，但在真实世界中总是存在很大缺陷。你可以构建自己的脚手架函数，但这不是我尝试过的东西。

关于“中间层”的问题，例如将您的视图模型映射到POCO，我强烈建议使用像AutoMapper这样的映射库。然后，您的控制器代码最终会变成这样（未经语法错误测试）：

[HttpPost]
public ActionResult Edit(int id, YourViewModel model)
{
    if (ModelState.IsValid)
    {
        var poco = repository.getPoco(id);
        Mapper.Map<YourViewModel, YourPoco>(model, poco);
        repository.Save();
        return RedirectToAction("List");
    }
    return View(model)
}

- Beyers

---

谢谢你的回答 - 在 asp.net 论坛上也有人建议使用 AutoMapper，我会试一下。至于脚手架 - 这正是我担心的，我开始使用这样的东西，迟早会遇到瓶颈，不得不花费大量时间创建“解决方案”（我以前就遇到过这种情况;]）。 - user2384366

Answer 2

你觉得上述内容“正常”吗？对我来说看起来很正常。另一个方法是首先创建单元测试。"没有时间进行单元测试"这种说法非常糟糕。我认为这简直不是真的。

让我解释一下： 如果你没有单元测试地实现一个功能，那么你通常无法早期发现简单的错误。这意味着你需要更多的时间来实现它，因为你需要额外的时间在实现功能后修复错误。

第2和第4点并不是真正必要的。想象一下，你可以先使用一个简单的“内存”存储（也可以用于单元测试）。你真的可以稍后再创建数据库和表。

often have to create nearly a duplicate of POCO entity, then - during save procedure, I need to convert it back to the appropriate POCO entities, usually like this:

PocoEntity1 pocoEntity1 = new () 
{ 
  UserName = ViewModel.UserName,
  UserPicture = ViewModel.UserPicture 
  (and so on) 
}

我非常同意你的观点，有时候这确实很繁琐。但是...有一个解决方案。使用AutoMapper（有一个nuget套餐）。

引用：

上述方法非常耗时且容易出错。另一方面，如果我直接使用POCO，我将不得不添加许多属性，例如：

[...]

这是不可取的（有时我希望根据视图有不同的属性名称）。

为此，还有另一个很好的帮助库：Fluent Validation（MVC）。

这简单地允许您为视图模型创建验证器。通过这个，您可以为同一个视图模型创建许多验证器 - 而不需要直接装饰任何模型。

- CodeTherapist

---

对于Fluent Validation我给出了加1的评价，因为它不需要装饰模型，但是我对AutoMapper持中立态度。起初我喜欢它，但随着使用次数增多，它变成了一个重构黑洞。 - ta.speot.is

@ta.speot.is 你能详细说明一下吗？我自己从未使用过AutoMapper，但它看起来很不错，而且似乎正好是用于上述工作的。为什么你认为它是一个重构黑洞呢？ - Andrew Savinykh

@CSharper：相信我，我知道应该先创建单元测试 - 但是现在根本没有时间，而以后会浪费更多的时间（很多很多时间 - 我知道），应用程序将会“准备就绪”，公司的账户上也会有现金；] 作为开发人员，我完全理解这不应该是这样的 - 但我的老板不这么认为 - “嘿，我们用这种方法创建了50个项目并得到了报酬，那你还抱怨什么？什么？意大利面代码？测试？谁需要测试人员，别抱怨了！如果某些东西能够工作，你就不要改变它！”- 试着打败这种“逻辑”吧;] 感谢其他建议。 - user2384366

@zespri “查找Domain.Entity.Property的用法”在到达ViewModel.SomethingLikeEntity.Property = Domain.Entity.Property之前停止，因为在调用var somethingLikeEntity = Mapper.Map<SomethingLikeEntity>(domainEntity)时没有直接使用Domain.Entity.Property。祝你好运，将Property移动到其他实体并更新用法 - 你的代码将编译，但你的模型会微妙地缺少Property。 - ta.speot.is