2008-08-30 42 views
9

因此,我正在着手ASP.NET MVC项目,虽然整体体验很好,但我对控制器已经变成的意大利面混乱感到不满意。我在网上查了一下(CodeCampServer等),他们似乎都遭受了相同的问题,其中控制器方法违反了SRP(单一职责原则)相当一致 - 如控制器方法,如果请求是简单地呈现视图一个GET,但更新模型,如果它是一个POST。现在我已经掌握了在整个应用程序中负责多个逻辑路由的控制器方法 - 比方说它检查在表单上点击了哪个按钮并相应地执行操作。我可以使用JavaScript将每个按钮点击重定向到不同的表单动作,但是有些东西感觉不太正确......另一个大问题是魔法字符串的泛滥 - ViewData [“foo”] = blah;长话短说,你们如何构建你的控制器逻辑?每个视图有一个巨型模型对象?很多小控制器方法和JavaScript是路由器?我的目标是可维护的代码 - 随着功能的堆积,我开始向下滑动该滑坡...ASP.NET MVC:结构化控制器

回答

8

ASP.NET预览版5(可在CodePlex上找到)有一个答案:[AcceptVerbs]属性。菲尔哈克有一个blog post讨论如何使用它。

至于视图数据魔术关键问题,这是一个有趣的问题。如果您认为某个视图是一群半独立的组件(尤其是考虑到新的局部视图支持),那么制作一个强类型的模型就变得不那么理想了,因为这几个视图应该相对独立于另一个。

0

不同的人是如何处理这个问题的?我知道我只花了几个小时来查看模型文件夹中的混乱。我发现创建文件夹有助于减少视觉混乱,使用匹配的命名空间也有很大帮助。

但是我的控制器目前是庞然大物。问题在于,我一直专注于学习项目中的这一点(还有很多需要理清的地方)。

我现在已经很好地掌握了MVC,所以现在是复习复杂性并考虑将控制器修改为更好的命名和更清晰的功能的时候了。

其他人是否将他们的控制器分解为子控制器? (如果有这样的事情)

+0

编码你的控制器的诀窍是看看他们并说'如果每个行动方法是超过20或30行或一些相对较小的数字,我该如何减少它?',基本上,保持它干燥,重新思考你在做什么,并将该逻辑移入适当的SERVICE层,可以重复使用。 – 2008-11-13 13:16:46