各位在使用mvc的时候会不会把controller拆成单个程序集，对应的model也拆成对应的程序集呢？
1
悬赏园豆：30
[已解决问题]
解决于 2019-01-11 14:42
各位在使用mvc的时候会不会把controller拆成单个程序集，对应的model也拆成对应的程序集呢？
这样拆开的唯一好处就是程序集按需加载比较快吧！但是程序集过多又有什么副作用呢，
想听听各位大侠的看法。。
问题补充：
我现在的项目架构是这样的：
Controller.poject----每个模块的Controller现在也独立成一个项目
Services.project----由wcf公开，对接的是Interface中的业务方法
Manage.Interface.project---公开业务逻辑API（针对每个Controller都有一个Manage）
Model.project---包含model和ViewModel（我还在想把model.project合并到Manage业务路径项目中。。。这样就不用加载全部的model.project项目了）
controller调用service公开的API。Service再调用Manage.Interface公开的业务逻辑API。。
你们觉得这样做的优劣是什么呢？请看我上面提出的疑问
感谢你们的参与讨论，最近我在忙些事，过段时间我再好好研究下再回复你们我的新想法
最佳答案
0
不太理解你的意思啊。
在一个UI里往往要用到很多model的，所以我都是在UI层又增加了很多ViewModel，大点的项目中，这些ViewModel在service层用基础Model组装一下(简单项目我就直接在controller里组装)。通过反射直接用service，所以controller中每个方法只有很少的代码。
你说的是不是这个意思？可以探讨一下。
收获园豆：25
我吧ViewModel也放到domain.model里了，只不过没有做数据库映射等。
@kylin.chen: 我补充了问题，请看下
@滴答的雨: 我对MVC也是刚学，尤其架构不是很在行。一起讨论啊，不对的地方请指教。
1、model你整合进去就是为了减少一个DLL引用吗？如果这个目的，我认为没必要。
2、为了用ORM框架，我认为model单独更好一些，园子里也有用充血model(就是带有CUD等方法)。
2、我有一Application层，里面就是各个Service（叫Business层也可以），这不是WCF的Service啊，WCF中要用这些Service；
3、这个根据项目大小来决定Controller怎么调用服务，如果仅是web项目，且没有移动的（单一界面），那么直接在Controller层里用Application层的Service就好，如果项目比较大，且多界面最好通过WCF呼叫Service提供服务。
4、个人经验：层分的越多，项目越复杂，项目管理成本会相对上升。这个要慎重！！
提供一个连接，不知道你看过没有，实际上我们是讨论架构问题了。看过这个连接，有很多启发的。
http://www.cnblogs.com/legendxian/archive/2012/06/18/2553111.html
@滴答的雨: 我认为你把Controller拆分，实际上就是我的application层的东西。不知道说的对吗？
@kylin.chen: 感谢你的回答。这个链接他刚发贴的时候看过，不过那时候看不懂！！！我晚上回去再看看先
其他回答(3)
0
一般没怎么拆分。至少我经历过的项目，都没拆分。
我补充了问题，请看下
@滴答的雨: 你这命名偏java化呢。拆分开呢，依赖要小些，发布的时候也能更好的增量发布。
@幻天芒: 程序集很多呢，有没有什么影响啊（命名中没有.project后缀的。这个只是为了说明是程序集）
0
我也还在摸索，负责的两个项目 用两种方式，一个拆到不同程序集，一个拆开到Areas。
拆程序集：
拆开的话发现有很多问题，先不说编译速度更慢了，重点在于解耦 各模块关联程度比较高（比较复杂的业务系统）拆开后只能把公共的全部单独分离。依赖关系复杂化了。
拆Areas：
因为 controller 存在的目的很明确就只接收请求，再调业务代码跑具体业务。
因为都在Web项目内了 只需要引用业务层，然后通过MEF来实现IOC 耦合度降低了 编译速度也快了很多。
唯一缺点就是团队分工不好划分权限了，因为负责模块的人只有具体模块的代码，项目文件经常容易冲突。
收获园豆：5
感谢参与讨论，最近我在忙些事，过段时间我再好好研究下再回复你们我的新想法
你后面补充的这个分层，实际上就是比较常见的三层模式：
1、业务逻辑层 对应你的interface
2、数据逻辑层你没有说，就是持久化（数据库的增删改查）
3、展示层 对应你的controller
我猜你最初的做法是把大量的业务逻辑写到了Controller层了，以至于你的controller很臃肿，一般的做法是controller直接调用业务逻辑层的方法，除了界面上的判断和model的组装以外，没有任何逻辑代码。关于wcf层，一般是为了减少服务器的负担和项目的灵活性，增加的一层，小项目基本可以不用。
项目分层有几个原则吧，我说的不一定对啊。
1、要考虑设计的方便性，就是说行业设计人员不懂程序，他就懂设计，会UI工具，所以分层符合流行UI工具的设计；因为设计阶段不涉及任何语言，与开发语言无关性。
2、要考虑项目的开发成本和速度，比如一个ERP项目，每天生产订单几万条，如果你分层越多，考虑速度问题，可能额外要做很多事情，如果简单三层架构可能更好；另外该类项目变更较快，层越多二次开成本越高（注意不是修改成本）。
3、加密性，为了控制项目被倒卖，经常将一部分核心业务逻辑转到存储过程中，然后加密，这个在oracle数据库的程序中也挺普遍的。这样业务层的东西就转移到数据库里了，破坏了数据库无关性的设计。
4、定制开发和开发产品的不同，定制开发考虑开发成本，开发的成本越低越好，产品考虑维护成本，所以产品一般分层都比较好，定制开发需求为主，往往分层很少，修改比较灵活，用的时间也最短。
5、行业的特点，比如博客论坛类的程序与电商的程序就不同，要考虑并发性，还要考虑多数据库的问题；制造行业的程序与这些又有很多不同，往往只有一台数据库服务器。另外，业务逻辑的复杂性也不同，比如购物订单的处理逻辑就比较清晰简单，但制造行业的订单就非常复杂，存在审批流和不同节点的修改问题。
6、项目团队的合作，每一层都能独立进行开发，对外公布接口，这样有利于团队合作和测试工具的使用。
0
楼主你好，我现在也在研究把model层独立项目的问题，期间遇到很多麻烦啊，model在view中赋值后提交给controller后不能用model的类整体接收了，请问这是怎么回事啊？
你前端数据问题吧，传递到Controller中的json数据，会对应的转化到接收的Model中
