关于业务逻辑 方法如何设计的问题

[美丽大道]

请教个问题 业务逻辑 如何来划分...

比如说 我有个订单表 还有订单明细表 是不是业务逻辑应该与具体表无关 直接就是 订单的逻辑

另外颗粒度细到那个程度.


比如说我模块分两大模块: 卖车和修车

卖车里面分为 订单 和进销存.
修车分为 卖配件和 维修..


我的业务逻辑是分为两部分:卖车和修车呢

还是分的更细些.....

请各位高手指点.

[於黾]

具体表是用来存放数据的, 不是逻辑根据表设计,正好相反,你的表应该根据业务需求而规划. 否则表结构定死了,许多业务实现起来很困难,或者根本无法实现.

[美丽大道]

那 车辆 进销存 应该分几个业务类呢 就一个么 车辆业务类 还是 车辆入库 一个业务类 车辆出库一个业务类 车辆调拨一个业务类 就是大概分到哪个程度

[於黾]

还有,业务是根据需求而定的,你应该多跟用户沟通,而不是闭门造车 否则就不是他们想要什么功能,你就给他们做什么功能,而是你做成什么样,他们就只能按你的思路去干

[美丽大道]

我只是问问类文件 如何划分 . .... 请说些有用的话. 你能凭借我寥寥数语就断定我闭门造车,没根用户沟通了...何以见得呢....

[於黾]

至于进销存,出入库,其实它们都是同一个逻辑,入库就+,出库就-(就是形象的一说,不是真的直接做加减法) 出库和入库数据应该都是在同一个库存表里,里面有出库记录和入库记录 这样才能方便统计剩余 至于你给用户展现成几个页面/窗口,要根据用户习惯来定,是分成2个,还是放到一起

[於黾]

至于后台的类文件,应该把哪几个具体功能放到一起,其实都无所谓的. 还是看哪些功能之间有共性,适合放到一起,就放到一起呗. 比如卖车和卖配件,其实都是出库,可能在后台用同一个类就实现了,而不用分成2个类.

[美丽大道]

我说的不是窗体或者页面. ... 我说的业务逻辑的方法 如何归类..... 不能吧所有方法都放在一个类里面吧. 我按什么划分业务逻辑?

[smthgdin_020]

订单表和订单明细都属于订单业务的一部分。

[smthgdin_020]

引用 7 楼 UnStopable 的回复:

我说的不是窗体或者页面. ... 我说的业务逻辑的方法 如何归类..... 不能吧所有方法都放在一个类里面吧. 我按什么划分业务逻辑?

有个叫OrderService这类的类,里面的方法再包含对订单和订单明细操作具体方法。对于上面一层,或者对于外部,她提供的是一个业务操作。

[会飞的溜溜]

引用 楼主 UnStopable 的回复:

请教个问题 业务逻辑 如何来划分... 比如说 我有个订单表 还有订单明细表 是不是业务逻辑应该与具体表无关 直接就是 订单的逻辑 另外颗粒度细到那个程度. 比如说我模块分两大模块: 卖车和修车 卖车里面分为 订单 和进销存. 修车分为 卖配件和 维修.. 我的业务逻辑是分为两部分:卖车和修车呢 还是分的更细些..... 请各位高手指点.

更详细点好：买车，修车，库存（二级目录 车辆库存；配件库存....），型号...用户管理

[美丽大道]

恩 明白了.我先这么弄着试试吧.不行再说.