实体类Model与UML设计的一点困惑

龟叔啊 2016-02-26 03:10:21

加精

本人只是一个普通的程序员，从事软件开发工作已有三年了，共在两家公司工作过，但接触的项目都是用动软生成器生成三层架构，数据库实体类model，作为参数在各层之间传递，我也用习惯了。今天突然想自己尝试uml设计，于是对现有项目自己尝试设计下，但在实际应用中发现与model好像有点冲突，想请教大家应该是怎么做的，下面举例下：
场景：市民到社区申请办理一孩生育服务证，需要提交相关材料由计生工作人员审核后录入进系统并生成一孩生育服务证书。群众需要提交的信息包括：个人信息（姓名、身份证号、户籍地、常住地）、配偶信息（姓名、身份证号、户籍地、常住地）、申请材料（结婚证、户口、身份证等），系统需要保存的信息包括：用户信息（个人信息和配偶信息）、申请材料、申请信息（申请人、录入人账号、申请日期）、证书信息（证书编号、发放日期、发放人）。现在要对业务逻辑进行设计，我可能设计成这样：

可能上述设计有不好的地方，先放过它，我主要的困惑的地方是因之前数据库模型封装成Model模型分别是：用户信息表、申请材料表、申请信息表、证书信息表。那么Model如何才两个类中进行传递呢？我就设计成这样：

上图中的字段类型都是一个model类型不是string，那么客户端使用时就可以创建各Model实例，将它赋给相应类的字段，通过类方法再传递给DAL进行数据的保存工作。
页面aspx.cs模拟使用方法：
//创建实体类
用户信息 user=new 用户信息（）；
User.name=text1.text;
…………………
申请材料 m=new 申请材料（）；
申请信息 apply=new 申请信息（）；
Apply.addtime=datetime.now;
………….
证书信息 certificate=new 证书信息();
Certificate.no=34523234234;
………………….
//创建业务逻辑类
市民 a=new 市民（）；
a. 用户信息= user；
a.申请材料= m;
计生工作人员 b=new 计生工作人员();
b. 申请信息= apply；
b.证书信息= certificate;
a.提交申请（b）;

但一看好像不对啊，从对象包含的特性角度来讲计生工作人员就不可能有申请信息和证书信息两个特性，因为这两个应该属于保存数据库后产生的信息也不属于用户的特性，那么我们应该将两个申请信息和证书信息两个model在哪创建出来并最终传递给DAL层呢？是否model与我在设计时思考的方式就是两种不应该存在？本人菜鸟不知道如何是好，我们技术经理是这样告诉我的：“如果你是按照第一张图去设计的，那么model就应该放在各具体实现业务逻辑中去创建不属于特性”，大概意思就是上述的计生工作人员录入方法体中去NEW出申请信息和证书信息并将其用户提交的信息和计生工作人员本身的特性进行赋值，最终将此model传递给DAL层。大家是这样做的吗？如果不对应该是怎么去设计的呢？

...全文

3095 23 打赏收藏转发到动态举报

写回复

用AI写文章

23 条回复

切换为时间正序

请发表友善的回复…

发表回复

gxt121244 2016-08-18

打赏
举报

数据库的模型与视图的model 是分开的。一个是存储的逻辑性，一个是展示的完整性。具体的业务逻辑你在bll 中处理

龟叔啊 2016-03-01

打赏
举报

谢谢大家解答，我正在学习相关视频，之后重新考虑设计看看。

wanghui0380 2016-03-01

打赏
举报

保存跟设计无关，太多程序员把DO当逻辑模型了（ps：ef code first出来的时候我是第一赞成地，现在我则反对，就是因为有太多太多程序把do当逻辑了，东西是好东西，但是误用的话，比不用更坏事）现在我说这样一句，如果他们都不是保存在数据库呢，如果有一部分在你的系统，另一部去了第3方系统，那又如何？？保存（持久化）是保存的事情，他和逻辑没有关系。逻辑对象需要的东西，也许一个数据库，一个表够用。也许需要多个库，多个表，多个存储介质。（也许我要写一条数据，要跟国际刑警的重点人员跟踪记录有关联系，难道你还有困惑我这个逻辑会怎么搞么，明显不会，你只是使用你的逻辑对象去操作，至于如何读取，如何保存，当然用国际刑警的api，他们自己操作自己的库，跟你没关系，如果是我说的这种介入情况，很明显你不会困惑，你困惑的是就你自己的一个系统。而我们说一个系统和多个系统没啥区别，逻辑上我们不关心他存哪里，怎么存。淘宝会用几百台机器存你一个人信息，你相信么？我可以相信，也许我的整个购物信息和个人信息是分布在几百台机器上滴，这点我认为完全可能）

ludahuwomiao 2016-03-01

打赏
举报

足球中国 2016-02-29

打赏
举报

微软当年弄出来个datatable.dataset这个东西。说是内存数据库就是一个浪费内存的玩意。用不好一个大狗屎。所以尽量别用了。什么三层，什么框架，大程序都是死磕出来的。

以专业开发人员为伍 2016-02-26

打赏
举报

引用楼主 heather_suyisi 的回复:

可能上述设计有不好的地方，先放过它，我主要的困惑的地方是因之前数据库模型封装成Model模型分别是：用户信息表、申请材料表、申请信息表、证书信息表。那么Model如何才两个类中进行传递呢？

你认为出现在数据库模型中的，不出现在第一张图中吗？一旦你从业务逻辑方面来考虑软件设计，那么数据库模型算个屁啊？！你的“用户信息表、申请材料表、申请信息表、证书信息表”为什么不在第一个图中画出来？自己是被哪一个教师蛊惑，而忘记了在第一个图中画这些必须的东西。能回忆出来吗？

以专业开发人员为伍 2016-02-26

打赏
举报

引用 10 楼 heather_suyisi 的回复:

[quote=引用 6 楼娃都会打酱油了的回复:]底层就是数据库模型，一般也就是dto，业务部分用业务模型bo，然后两者的转换在业务层完成，最终展示时还可能会有视图模型vo

有点明白你的意思了，就是说业务模型跟数据库模型两者分开设计的，那么从业务模型中的逻辑去转换为需要的数据库模型传给底层？那么意味着页面层不会new数据库模型，只会new出业务模型然后将所需数据赋给业务模型字段，最终在业务模型逻辑方法中转换为数据模型传递给数据层，是这个意思吧[/quote] 你把你的说法中的所有动词都抽出来，看看，这些时髦的名词都有没有它的“根”呢？什么“在类间传递、转换为需要的数据库模型”等等，完全是没有根据的纠结技术问题。而你的问题不是技术问题，而是你根本就不在建模时先把最基本的数据模型之间的关系画出来，这是一个“懒惰”问题。假设在第一个图中把申请信息和证书信息放到模型里，那就先把数据结构落地了，还会在后边那么多的标题党式的问题吗？滥用动词而不先把背后的数据关联（名词）画出来，一眼就能看出这是标题党的描述方式。

以专业开发人员为伍 2016-02-26

打赏
举报

首先，动软生成器既不是什么“生成三层架构”（因为它根本不可能懂业务逻辑层设计，它只会用你的数据库来产生一层坑爹的、假的业务逻辑层“），动软生成器也不是你搞不明白对象实体模型的理由，因为动软生成器只是一个数据表到一些class的傻瓜化的对应关系（而且这些class并不包含纯粹从业务逻辑层而分析出来的 Model），不要对它有什么其它期望。设计不出来表间结构，不要拿动软生成器来说理由。再来看你的第一个图，它完全没有申请信息和证书信息，那么你的目的是什么呢？你接着说“可能上述设计有不好的地方，先放过它，我主要的困惑的地方是因之前......"，这里我觉得你如果这样来对待设计，那么可能就不适合再继续搞编程设计了。静态关联模型既然出了问题，既然”先放过它“，那么你就应该把跟你放过的相关的所有动作都放过。怎么又来空洞地追求“如何才两个类中进行传递”这类看不懂的话呢？我猜只有你的技术经理看得懂，因为他负责招聘你。从我的角度，我觉得你现在不适合找工作，而应该上学。但凡想糊弄过关的实习生（注意是实习生，而不是正规试用员工），通常都会那一个类似“提交申请”这样的动词来糊弄领导，好像他已经写出来了与（多次）申请行为有关的数据结构。而实际上呢？如果连申请信息和证书信息与用户信息和计生人员信息之间的关联都没有建模，那么你后边的一切动词不用看你的代码、它都就是空话。

龟叔啊 2016-02-26