大牛进！跟技术主管发生分歧了，MVC中的Controller是否可以使用继承来写Action??

idoiknow 2013-02-27 11:31:37

关于MVC路由的问题。

项目里所有的Controller都是从一个BaseController中派生的。

BaseController里面我加了一个虚方法,是写成Action的,有逻辑实现,目的是实现一个通用的功能,如果某些Controller的这个Action需要特殊处理的,就在具体的Controller里面重写这个虚方法,否则默认调用基类的虚方法的执行逻辑。

但技术主管说这个不行,他没见过这样写的，会有两个路由什么的...balabala

我无法理解他的观点,感觉这样写也没有什么问题,请教各位大牛,这样写会有弊端吗?

贴代码:
(基类)
/// <summary>
/// 所有ReportController都要继承的基类
/// </summary>
public abstract class BaseController
{
[HttpPost]
public virtual JsonResult AddIssueReport(AddIssueReportModel inputModel)
{
//通用实现逻辑
}
}

(具体Controller)
/// <summary>
/// ***报表-控制器
/// </summary>
public class CanvassBusinessReportController : BaseController
{
/// <summary>
/// 重写基类的报表补发方法
/// </summary>
/// <returns></returns>
[HttpPost]
public override JsonResult AddIssueReport(AddIssueReportModel inputModel)
{
//特殊实现逻辑
}
}

...全文

860 20 打赏收藏转发到动态举报

写回复

用AI写文章

20 条回复

切换为时间正序

请发表友善的回复…

发表回复

铜臂阿铁木 2013-03-08

打赏
举报

引用 2 楼 idoiknow 的回复:

引用 1 楼 sunzongbao2007 的回复:只要可用可读可维护，没什么不行的我也这样认为,但老大着眼于更高层次的可维护,什么交叉引用、依赖倒置...各种高端玩意

过度设计永远是不对的

Kilin_Zhang 2013-02-28

打赏
举报

派生Controller跟路由有个锤子关系

gengchenhui 2013-02-28

打赏
举报

让他拿出一个解决方案来。

yyl8781697 2013-02-27

打赏
举报

引用 3 楼 still_melody 的回复:

假如你是对的，胳膊拧不过大腿假如你是错的，你们老大可能真是站的高，看的远

这尼玛，说得好我也没看出什么来， LZ可以问你们技术主管：对这几个会出现意外情况给出几个情景来，不然说个毛啊

人傻且呆但不萌 2013-02-27

打赏
举报

可扩展，可维护，有什么不好的？某些人总是将自己不熟悉的归于非安全的。

idoiknow 2013-02-27

打赏
举报

引用 3 楼 still_melody 的回复:

假如你是对的，胳膊拧不过大腿假如你是错的，你们老大可能真是站的高，看的远我分不出对错。只能与楼主共勉。期待自己看清的那天

呵呵,共勉,早日看清~

still_melody 2013-02-27

打赏
举报

假如你是对的，胳膊拧不过大腿假如你是错的，你们老大可能真是站的高，看的远我分不出对错。只能与楼主共勉。期待自己看清的那天

idoiknow 2013-02-27

打赏
举报

引用 1 楼 sunzongbao2007 的回复:

只要可用可读可维护，没什么不行的

我也这样认为,但老大着眼于更高层次的可维护,什么交叉引用、依赖倒置...各种高端玩意

铜臂阿铁木 2013-02-27

打赏
举报

只要可用可读可维护，没什么不行的

idoiknow 2013-02-27

打赏
举报

引用 16 楼 fangxinggood 的回复:

从名字来看并不是所有继承类都需要，为什么不再设计一个基类使得功能进一步具体化（需要这个Action的子类派生于此）

果然眼光犀利，被你发现了今天我和主管讨论时他有提及到的一个做法，但是后面他又说这样也不行，还是路由对应什么的会存在问题，balabala 我始终想不通，派生类初始化后，基类相当于就嵌入到派生类里面，怎么还会导致路由受影响呢？难道说MVC的机制是先处理路由，找到Controller，然后这个Controller才开始被实例化？还有我们现在是用了依赖注入的，Controller的构造方法的参数是接口性的，而不是具体类型的，所以这些接口类型与具体类型的匹配会有一个特殊的处理过程。总之IoC就是了，大牛们都懂的。难道是这个地方会有影响？应该也不至于，因为基类的构造方法使用到的若干个参数是在派生类的构造方法里面传入的。也就是base(Iservice param)这样子,这是老大自己定好的规则。

机器人 2013-02-27

打赏
举报

从名字来看并不是所有继承类都需要，为什么不再设计一个基类使得功能进一步具体化（需要这个Action的子类派生于此）

idoiknow 2013-02-27

打赏
举报

引用 8 楼 ly_sl 的回复:

没感觉有什么问题，唯一可能有问题也许是怕逻辑更复杂吧。LZ可以和你们的技术主管讨论下。

咱这技术主管不好沟通啊，整个部门的人都跟他沟通不来，想我这样比较拽的人就更加跟他沟通不来了，哈哈~ 玩笑话，其实还是要尽力沟通的...

idoiknow 2013-02-27

打赏
举报

引用 5 楼 nice_fish 的回复:

可扩展，可维护，有什么不好的？某些人总是将自己不熟悉的归于非安全的。

其实我也这样觉得，我只考虑可见的范围内的安全性，所以觉得一切简单，而他则喜欢对别人提出的观点穷尽所有预测来苛责你。我本菜鸟，所以无畏。

idoiknow 2013-02-27

打赏
举报

引用 11 楼 winner2050 的回复:

人家不是在征求意见。你在行使人家的职权，你要人家作什么，你要作什么？写个大致能通用的基类，特殊的自己另外实现。让程序的特殊性零星分散到各个地方？我看不是好主意。

你说的很对，如果不从技术方面讨论的话，貌似主管的意思就是给我一个下马威。因为我在部门开发群里发了几条关于自己在这个模块的重构说明并通知其他人做特殊性处理。也许让他感觉我太自作主张，抢他风头。其实这个模块的现状就是：四十几张报表，每一张都是独立的Controller，下发、填写、查看...这些动作由各个Controller里面的Action自行处理，但我觉得不同Controller里面对应的Action里面的处理代码其实是非常冗余的，大部分都相同。好吧，这些都已经写好在那里了，我也没什么意见了，现在我要做一个补发动作，然后我觉得没必要继续采用他这种做法，可以抽象出来，因为大部分报表的补发其实是从已下发的报表那边取到数据，所以相对比较简单，个别特殊报表就在自己的Controller里面重写我的补发方法。实际上我完成了这个补发的功能，实际运行也没发现有什么问题，一切都很Ok，所以也没有去和他协商啊什么的，而且他是那种很难沟通的人，讨论个问题都搞得像是和他有杀父之仇夺妻之恨一样，So~~ 他也没给解决方案，如果四十几张报表每一张都加补发动作处理Action，四个程序员各自改各自的代码，我觉得比较浪费人力。哎，自己火候不到，真难，说句话都被人家用几个高端字眼给弹压回去了。