|
|
5 回复 | 直到 12 年前
|
1
8
我想你在找
Areas in ASP.Net MVC 2
. 在csproj文件中有一些东西需要取消注释,但在这之后,它将在您构建时复制视图。我不认为有任何要求
Walkthrough: Creating an ASP.NET MVC Areas Application Using Multiple Projects |
|
2
8
控制器: 不过,你不应该做任何特别的事情,把控制器扔进他们自己的程序集。您最多只需重写controllerFactory的getControllerType方法。 模型: 对模型放置位置没有限制。尽管这不适合我,但我经常使用来自nhibernate/其他orm层或wcf/服务层dto的持久对象,这些对象位于单独的程序集中作为我的视图。这作品 使用webforms的相同方式 . 意见: 单独程序集中的视图必须标记为嵌入资源,然后必须使用自定义 VirtualPathProvider 他们知道如何从资源而不是文件系统获取视图。 views from an resource instead of the file system . 这又是 完全相同 用于Webform开发的技术。 关于麦金太尔321和他的便携式区域回答: 链接的项目几乎不做任何自定义的事情,只是将现有的mvc 2扩展点包装成一个更易于使用的抽象。它几乎没有“习惯”和更多的语法糖。 你管理一个大型MVC应用程序就像管理其他大型应用程序一样。我害怕打开一个500页的webforms项目,因为你永远都不知道每一个代码后面的内容。使用mvc,不同的功能大多在其正确的位置。一点也不相反。 |
|
|
3
6
将代码分离为单独的程序集与关注点的分离是正交的。代码所在的位置不是“关注点”。关注点的分离与各个组件的职责和依赖关系的方向有关。例如,视图负责呈现输出,控制器知道视图,但视图并不真正了解控制器。 和ewile一样,模型对视图和控制器都不了解,但是视图和控制器都会了解模型。 不过,回到你的问题上来。正如jfar所指出的,将控制器和模型移动到另一个程序集中非常简单,而且可以工作。将视图移动到另一个程序集中更为困难。具有自定义虚拟路径提供程序的嵌入式资源是一种方法,但对于高性能站点,我们通常不建议使用这种方法。但如果它满足你的需要,就去做吧。 |
|
|
4
1
MVC是非常可扩展的,不需要遵循控制器、视图和模型文件夹结构。您可以将控制器放置在任何您想要的地方,但是如果它们位于另一个程序集中,则需要实现自己的控制器工厂,该工厂知道如何定位它们。 Here 是使用Windsor定位控制器的示例。 您的模型/视图模型可以在任何您想要的地方。您只需要在web.config中引用它们的名称空间,这样视图就知道要查找的位置。(至少我知道火花视图引擎是这样的。) 你把你的观点放在任何一个网络项目中。我通常的策略是创建一个包含views文件夹的纯web(非mvc)项目。(这甚至可能是一个遗留的web应用!)然后我所有的控制器都放在一个单独的类库中。我的视图模型和服务进入另一个。 至于组织文件夹,我通常将层次结构集中在域概念上。我会在每个项目中为用户、产品、订单等创建一个文件夹。我从来没有在任何地方创建过模型或控制器文件夹。 |
推荐文章