首页 新闻 搜索 专区 学院

各位在使用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。。

 

你们觉得这样做的优劣是什么呢?请看我上面提出的疑问

 

 

感谢你们的参与讨论,最近我在忙些事,过段时间我再好好研究下再回复你们我的新想法

滴答的雨的主页 滴答的雨 | 老鸟四级 | 园豆:3690
提问于:2013-06-19 10:51
< >
分享
最佳答案
0

不太理解你的意思啊。
在一个UI里往往要用到很多model的,所以我都是在UI层又增加了很多ViewModel,大点的项目中,这些ViewModel在service层用基础Model组装一下(简单项目我就直接在controller里组装)。通过反射直接用service,所以controller中每个方法只有很少的代码。
你说的是不是这个意思?可以探讨一下。

收获园豆:25
kylin.chen | 小虾三级 |园豆:983 | 2013-06-19 11:49

我吧ViewModel也放到domain.model里了,只不过没有做数据库映射等。

kylin.chen | 园豆:983 (小虾三级) | 2013-06-19 11:50

@kylin.chen: 我补充了问题,请看下

滴答的雨 | 园豆:3690 (老鸟四级) | 2013-06-19 12:03

@滴答的雨: 我对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

kylin.chen | 园豆:983 (小虾三级) | 2013-06-19 13:25

@滴答的雨: 我认为你把Controller拆分,实际上就是我的application层的东西。不知道说的对吗?

kylin.chen | 园豆:983 (小虾三级) | 2013-06-19 13:27

@kylin.chen: 感谢你的回答。这个链接他刚发贴的时候看过,不过那时候看不懂!!!我晚上回去再看看先

滴答的雨 | 园豆:3690 (老鸟四级) | 2013-06-19 17:15
其他回答(3)
0

一般没怎么拆分。至少我经历过的项目,都没拆分。

幻天芒 | 园豆:36594 (高人七级) | 2013-06-19 12:00

我补充了问题,请看下

支持(0) 反对(0) 滴答的雨 | 园豆:3690 (老鸟四级) | 2013-06-19 12:03

@滴答的雨: 你这命名偏java化呢。拆分开呢,依赖要小些,发布的时候也能更好的增量发布。

支持(0) 反对(0) 幻天芒 | 园豆:36594 (高人七级) | 2013-06-19 12:57

@幻天芒: 程序集很多呢,有没有什么影响啊(命名中没有.project后缀的。这个只是为了说明是程序集

支持(0) 反对(0) 滴答的雨 | 园豆:3690 (老鸟四级) | 2013-06-19 13:01
0

我也还在摸索,负责的两个项目 用两种方式,一个拆到不同程序集,一个拆开到Areas。

拆程序集:

拆开的话发现有很多问题,先不说编译速度更慢了,重点在于解耦 各模块关联程度比较高(比较复杂的业务系统)拆开后只能把公共的全部单独分离。依赖关系复杂化了。

拆Areas:

因为 controller 存在的目的很明确就只接收请求,再调业务代码跑具体业务。

因为都在Web项目内了 只需要引用业务层,然后通过MEF来实现IOC 耦合度降低了 编译速度也快了很多。

唯一缺点就是团队分工不好划分权限了,因为负责模块的人只有具体模块的代码,项目文件经常容易冲突。

收获园豆:5
Y2zz | 园豆:393 (菜鸟二级) | 2013-06-29 01:57

感谢参与讨论,最近我在忙些事,过段时间我再好好研究下再回复你们我的新想法

支持(0) 反对(0) 滴答的雨 | 园豆:3690 (老鸟四级) | 2013-07-13 17:41

你后面补充的这个分层,实际上就是比较常见的三层模式:

1、业务逻辑层 对应你的interface

2、数据逻辑层你没有说,就是持久化(数据库的增删改查)

3、展示层 对应你的controller

我猜你最初的做法是把大量的业务逻辑写到了Controller层了,以至于你的controller很臃肿,一般的做法是controller直接调用业务逻辑层的方法,除了界面上的判断和model的组装以外,没有任何逻辑代码。关于wcf层,一般是为了减少服务器的负担和项目的灵活性,增加的一层,小项目基本可以不用。

支持(0) 反对(0) kylin.chen | 园豆:983 (小虾三级) | 2013-07-16 17:13

项目分层有几个原则吧,我说的不一定对啊。

1、要考虑设计的方便性,就是说行业设计人员不懂程序,他就懂设计,会UI工具,所以分层符合流行UI工具的设计;因为设计阶段不涉及任何语言,与开发语言无关性。

2、要考虑项目的开发成本和速度,比如一个ERP项目,每天生产订单几万条,如果你分层越多,考虑速度问题,可能额外要做很多事情,如果简单三层架构可能更好;另外该类项目变更较快,层越多二次开成本越高(注意不是修改成本)。

3、加密性,为了控制项目被倒卖,经常将一部分核心业务逻辑转到存储过程中,然后加密,这个在oracle数据库的程序中也挺普遍的。这样业务层的东西就转移到数据库里了,破坏了数据库无关性的设计。

4、定制开发和开发产品的不同,定制开发考虑开发成本,开发的成本越低越好,产品考虑维护成本,所以产品一般分层都比较好,定制开发需求为主,往往分层很少,修改比较灵活,用的时间也最短。

5、行业的特点,比如博客论坛类的程序与电商的程序就不同,要考虑并发性,还要考虑多数据库的问题;制造行业的程序与这些又有很多不同,往往只有一台数据库服务器。另外,业务逻辑的复杂性也不同,比如购物订单的处理逻辑就比较清晰简单,但制造行业的订单就非常复杂,存在审批流和不同节点的修改问题。

6、项目团队的合作,每一层都能独立进行开发,对外公布接口,这样有利于团队合作和测试工具的使用。

支持(0) 反对(0) kylin.chen | 园豆:983 (小虾三级) | 2013-07-16 17:15
0

楼主你好,我现在也在研究把model层独立项目的问题,期间遇到很多麻烦啊,model在view中赋值后提交给controller后不能用model的类整体接收了,请问这是怎么回事啊?

dzealot | 园豆:202 (菜鸟二级) | 2014-12-27 10:59

你前端数据问题吧,传递到Controller中的json数据,会对应的转化到接收的Model中

支持(0) 反对(0) 滴答的雨 | 园豆:3690 (老鸟四级) | 2014-12-30 15:00
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册