在asp.net mvc(4)中,开箱即用,视图进入Views
文件夹,然后按子文件夹中的控制器进行分组。
控制器进入Controllers
文件夹,(查看/编辑/输入)模型进入Models
文件夹等。
我喜欢视图的组织方式。但是,我不想横向打破其余的MVC片段。
我的问题是,将视图组织结构保持原样会有什么缺点,但是按控制器组合其他类(即通过用例)。 E.g:
/Home
HomeController.cs
IndexViewModel.cs
IndexViewModelBinder.cs
/Messages
MessagesController.cs
MessagesApiController.cs
MessagesViewModelBinder.cs
MessageViewModel.cs
MessagesListViewModel.cs
/Views
/Home
Index.cshtml
/Messages
MessagesIndex.cshtml
MessageDetails.cshtml
答案 0 :(得分:3)
重要的是View文件的排列,因为它们是在运行时访问的。其他所有内容都被编译到程序集中,因此源文件的物理位置无关紧要。
和我一样,我发现大型项目的默认安排有点尴尬,所以这就是我如何布置当前的项目:
~/
/Areas
/DefaultArea // I always use areas, even when there's only one, because it simplifies things when adding additional areas.
/Controllers
FooController.cs
/Views
/Foo
FooView.aspx // Yes, I use WebFormView. Just a matter of personal preference
FooEdit.aspx
FooModels.cs // this file contains my ViewModels
所以基本上,我将ViewModel类放在与视图相同的文件夹中,而不是将所有ViewModel放在一起(这使得逻辑上的意义不大)。我很想将我的控制器放在他们的视图文件夹中,但我决定反对它。
到目前为止,我发现我的方法没有任何缺点(现在已经使用了近两年)。
答案 1 :(得分:1)
我通常喜欢避免可能的区域,因为它会产生一些路由问题。
我认为你的结构完全没问题(并且优于基于“类型”分离代码的默认MVC / Web结构,而不是“功能”)。
我建议您只在Web DLL中保存“web”.cs文件(例如Controllers,ViewModels,Binders等),并在域/服务/等的单独DLL中具有相同的结构如果/根据需要,它们可以单独重复使用/测试。