组织ASP.NET MVC解决方案

我几个月来一直在研究一个大的ASP.NET MVC 3应用程序。直到项目后期，我才意识到我的控制器很大！这些控制器巨大的部分问题是我无法对它们进行单元测试。组织ASP.NET MVC解决方案

我，因为分裂已经控制器的责任分为四个任务（在我心中）：

导航
转换ID的数据对象
显示
一般建筑视图模型专用业务逻辑

由于某些业务逻辑是跨客户端和服务器端代码共享的，将它与视图模型构建器逻辑混合是没有意义的。所以，我立即看到至少需要两个项目：查看模型构建器和通用业务逻辑。

我意识到导航应该是控制器的责任，以便逻辑保留在MVC项目中。

我有点遗憾应该由哪个项目将ID转换为数据对象。最初，我将这作为业务类/视图模型构建器类的职责。不过，我想我希望这些类能够完全构建对象。所以，我不确定应该在代码中进行这种转换。这似乎并不关乎我在哪里做转换，代码变得重复。我一直在考虑在执行这些转换的相应项目中创建适配器，然后调用实际的业务类/视图模型构建器类。

有没有人在超越单个项目的ASP.NET MVC项目中工作？
逻辑如何分解以保持控制器的大小并保持代码可测试？

来源

2012-01-26 Travis Parks

有没有人在这已经超越单个项目的ASP.NET MVC项目的工作？

是。

如何逻辑爆发，以保持控制器下来的大小，并保持代码的可测试？

通过putting controllers on a diet。

来源

2012-01-26 06:58:36

我喜欢使用ModelBinders将键转换为对象的讨论。我认为当逻辑变得更复杂时，使用AutoMapper会开始崩溃。为此，我正在考虑创建视图模型构建器。当POST处理程序的逻辑开始变得更复杂时，此演示中使用的IHandler类开始变得与原始控制器一样讨厌。令人讨厌的业务验证逻辑还涉及更新ModelState。 –

这个演示的一个好处是它确认了我的最新方法正朝着正确的方向发展。我的控制器大部分操作都只有几行。我使用了很多ActionFilters，Ninject和业务逻辑层来减少我的动作大小。似乎我观察到了同样的重复主题。耶，我并不孤单！ –

链接的视频不再存在。 –

组织ASP.NET MVC解决方案

回答

相关问题