10.5w+
社区成员
- 主页
- C#综合技术
- C#互联网桌面应用
- AppLauncher
- WinForm
- WPF
- 问答
要开发一个控制调度系统，适合用三层架构吗？
最近要开发一个控制调度系统，有界面但是主要用于数据输入。适合用三层架构吗，我感觉三层架构好像更多的用于web开发，存在大量的页面显示和数据库交互。在这种控制系统中，用三层架构合适吗，或者应该如何用三层架构呢。
另外就是控制系统中有数据库，有多个表，主要用于存储控制系统中用到的数据。在数据库的设计上，是把所有的数据表写到一个数据模块中，对外提供访问各个表的接口，还是将每个数据表划分到不同的模块。每个模块提供对本模块数据表的访问接口，其他模块如果要访问数据表通过这个接口访问。哪种比较合理？
另外就是控制系统中有数据库，有多个表，主要用于存储控制系统中用到的数据。在数据库的设计上，是把所有的数据表写到一个数据模块中，对外提供访问各个表的接口，还是将每个数据表划分到不同的模块。每个模块提供对本模块数据表的访问接口，其他模块如果要访问数据表通过这个接口访问。哪种比较合理？
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
以专业开发人员为伍 2018-05-14
我再简化一下我的描述吧。
你根本没有要把这个系统垂直拆分为不同SOA子系统需求目标的时候，那么“应该根据数据表建立模块，或者说重新规划一下数据表”这个就是非常危险的做法，这个的出发点不是从你的系统的前端对外服务的分模块出发，而是从他认为的同一个数据库里边的数据表硬生生地自己意淫出来的分模块。当然他为了证明它使用到了三层架构概念，是要顺着你原来的模块的划分方法来划分，但是他一定要显得跟你说的概念名词儿不一样，所以选择了“三层架构”。碰上了你这么一个原本已经将通讯模块、业务服务调用模块设计的很独立的人，你恰恰不熟悉“三层架构”这么貌似高大上而实际上最简单的概念。
既然是同一个底层数据库，那么不同模块的 Model 定义在一起是可以的，不同模块分别定义自己的一堆 Model 也是可以的。使用 EF 之类的工具都是可以把多个高层次界面模块的底层数据表建立到同一个数据库系统的。这是你们自己的选择问题。
不要额外花费更多精力去写什么数据库模块，使用 .net 中现成的数据库操作框架，你只要定义一下数据模式就可以自动产生数据库表并且强类型地增删改查了。假设一个模块要调用另外一个模块的任务调度接口，那么走你原来调度就可以，不要再去弄出另外一套“提供数据表的处理结构”。
以专业开发人员为伍 2018-05-14
那你可以看你这个帖子的最初的描述，跟后边的实际矛盾问题的描述。我的回复的内部逻辑其实是前后一致的，不要只看表面字眼儿。对于网络软件设计开发，假设要做好、做大，那么自然要最起码地要设计中间层 BLL 服务，那么针对“多个模块”自然就过渡到考虑SOA、微服务之类的设计上。
我给你一个认识一些程序员的视角。有些程序员还是满脑子只有一些把一些 Model 对象能过够更加整齐地增删改查到数据库里边的 ORM 编程的概念，美其名曰“三层架构”，其是这不是真正的三层，这只是满脑子只有 DAL 的那些人的做法。
sp1234_maJia 2018-05-14
这是整个系统垂直划分为不同子系统的问题。就好像原来一栋大楼，现在要把设计且分为5栋楼组成的楼群，然后楼与楼之间搭建一些通道。
我已经说了，你后边的描述跟一开始的完全不同。我认为后边的说法中，你的感觉是对的，应该避免那位纠结于 DAL 封装的新同事影响你们的开发。“为了三层而三层”，不是真正的三层架构所需要的做法。
任何一个功能服务，如果要增删改查，那么就直接调用 EF 之类地去增删改查就好了。比如说“泵房监控”系统可能会直接调用有关质量检验的数据库 EF-Model，但是也可能是调用质量检验子系统的接口 API，这是上面说的“楼与楼之间的通道”，这个是你们自己的选择问题（因为你可以根据他们在同一个进程内，还是有可能SOA甚至微服务部署而重构）。但是这里的关键是说，完全没有必要额外自己写根据每一个业务 Model 来封装一套增删改查的 DAL 代码。那位同事所说的做法是许多年前的三层架构时髦时产生一股“生成器”的累赘繁琐会带来巨大的维护和修改成本、拖延时间的一种方式。
以专业开发人员为伍 2018-05-14
你原本有一整套划分从实际的前端往底层数据库去设计的方法，现在碰到一个人拿着数据库表就来硬生生地要重新设计系统，完全不从前端和服务接口设计出发来讨论重写系统的必要性，这样的“为了三层而三层”的程序员所强调的三层开发，其实就是反架构的。
以专业开发人员为伍 2018-05-13
对于“数据库模块”，你要用 .net 下各种数据库的高效率的、现成的框架，比你自己开发一套所谓的数据库模块的开发效率高几十倍，不要自己再搞什么 DAL 开发。针对数据库增删改查这部分功能是很成熟的，如果你不清楚用什么，那就用 EF。
以专业开发人员为伍 2018-05-13
至于“适合、不适合”这个对于初学者根本没有办法说清楚。
因为你首先是不会发布接口功能（连基本的 WCF 服务都不会开发一个）。那么假设一个人说它为某个软件发布了一套 WCF 接口——比如说发布了40个服务功能并且自认为基本上涵盖了最近2个月前端需求的主要接口功能，写了接口调用规范文档，这个时候你再来说“我觉得不适合用接口，我觉得前端只要直接打开数据库去随便删除数据就够了”那么就才能认真地讨论实践问题。
连服务接口都不知道怎样开发，谈什么“不适合三层”呢？
以专业开发人员为伍 2018-05-13
比如说一个人在餐馆点餐、然后下单给厨房、然后上菜、然后结账、甚至做出评价.......这些都是一个个业务逻辑API，这里传送的 Model 参数都是针对业务的，前端还管点餐涉及到4个还是5个数据表、涉及不涉及别的SOA服务？前端只要按照文档调用服务端接口就行了。
在开发中经常遇到这样的情况，前端分析了老板给的需求规格 word 文档之后，发现其中有3个功能没有直截了当的后台接口，于是找到服务端开发人员谈一下需求，服务端开发人员说“好，我明天给你实现这两个接口”。于是第二天，新的前端测试上线了，而数据库也增加了1个表、或者根本没有增加数据表——因为接口跟数据库表根本就不是一回事儿。
这是一个高效率的开发模式。当然假设你总是事后维护别人的程序，而自己没有参与过稍微复杂一点的项目，体会不到多人开发的最基本的要求。
以专业开发人员为伍 2018-05-13
我帮你理解这类同事。
你实际上已经在以前的项目中熟练使用三层架构，只是不自知，所以容易被忽悠。那位同事就是整天在增删改查上封装一堆代码，比如说 EF 一整套机制可以直接处理各种 Model，或者是 ADO.NET 可以直接增删改查，而那位同事喜欢把大家的时间用在针对每一个类型上面都重写一遍增删改查代码。写任何代码其实都有其适应、不适应的时候。但是你说的这个情况，这首先说这类做法就是“为了三层而三层”的方式，是多余的。
你们有一套通用的可发布的服务接口，这就是 BLL 层。这就是三层。
以专业开发人员为伍 2018-05-13
你说的“之前做web开发过来的同事”，我告诉你，做 web 的同事其实分为偏前端和偏（例如）aspx这一端的人。偏前端的人接触实质的千变万化的项目应用需求，更实际一些。（10年前）偏 aspx 这一端的程序员喜欢说“我不喜欢做前端，我就喜欢后端增删改查”，所以这类程序员整天纠结数据库表，而拖延前端软件开发进度。
如果你们在前端能开发出来产品，你们在开发服务接口方面能提供某一种服务，那么我建议辞退此类“之前做web开发过来的同事”，比较有利于敏捷开发。
以专业开发人员为伍 2018-05-13
满脑子纠结“数据表”那么口中的所谓“三层架构”基本上就都是假的。程序设计是从前端需求出发的，对前端千变万花的编程接口需求提出了设计规范，于是才有 BLL 层需求。比如说有50个数据表，那么你的服务 api 可能有20个，也可能有120个，这个数量完全是从表现层的逻辑需求而推演来的接口文档。把数据库表叫做变成接口需求（业务逻辑驱动层API）那么面对网络、分层、异构解耦、扩展等等，自然是一片空白了。
以专业开发人员为伍 2018-05-13
“切换数据库类型”，其实具体技术方面这还是 DAL 内部来做的。例如 EF 就可以通过修改配置来切换不同数据库类型，甚至你写 ADO.NET 代码时通过些比较通用的 sql 标准的语句、然后调用不同的参数来替换一些分隔符（例如 oracle 用 : 符号而 sql server 用 @ 符号）等等，ADO.NET 本身就已经是抽象了各种关系数据库的一套框架。三层的意思是设计一套用户需求的软件时就不要纠结于数据库表，所以从这个意义上说是可以方便于跨数据库——包括完全扔掉关系数据库系统概念而改用 NoSql 的机制。
但是你满脑子只有增删改查，所以我不说得太多。这就好像你还有肿瘤，却整天关心各种各样的小毛病对自己的情绪造成的体验，被那些卖保健品的假医生忽悠了，而可能耽误了彻底治疗一样。
三层架构很所有网络软件基本架构中最简单、最原始的一个。就是说你设计前端软件时要调用服务接口，而不是调用关系数据库。
suncs2001 2018-05-13
做模块设计的时候避不开这个数据表的处理划分啊。 其实对数据表的处理是不是使用三层架构到没有关系，只要能增删改查就可以了，并没有纠结这个地方是不是一定要三层。 纠结的是把对数据表的处理放到一个模块里还是分散到其他各个模块中。 哪种方式都能实现功能，只是纠结于哪种更合理一点。
以专业开发人员为伍 2018-05-13
唉跟什么“每个模块”根本没有这么纠结。你纠结的本质，还不就是因为忘不了数据库表吗？
三层就是说，前端要调用面向服务的接口、面向业务颗粒度地访问远程后端，而不是从前端访问数据库。你学过一点点 WCF、Remoting、Tcp 甚至 restful 之类的概念把？这些的应用时的设计方式都是面向后台服务开发，而不是面向数据库开发。
以专业开发人员为伍 2018-05-13
软件设计开发有很多事情要做。而把数据“持久化”其实就是一个超级简单地形式化方法，就是把 Model 增删改查到数据库里边。这个不应该花时间纠结，如果有了好的“数据操作引擎”那么你就直接使用就是了，自己开发DAL是最坑爹的事情。过去许多年前有些所谓的“生成器”不过就是帮人增删改查时写代码简单整齐一点而已，但是却把 ORM 忽哟成什么“三层架构”，结果造成了很恶劣的过，许多公司拿那种所谓的生成器来误导程序员脱离了软件设计的本质。这些生成器根本连领域分析文档都没有，怎么可能从 DB first 就知道该如何生成 BLL 呢？
今天基本上你完全不必开发 DAL，因为现成的 DAL 很多。甚至自己随便封装100行c# 代码能写出很好的 SQLHelper 也够用。你应该把精力用在交互界面、网络、服务设计之类的地方，而不是把时间动用来封装一大堆增删改查语句。
suncs2001 2018-05-13
我想表达的是这个意思：
我之前是搞C的，没有用过什么框架。 这次转到.net开发，面临的是我要做的系统的一个架构问题。我们的系统是个控制调度系统，接收从外部来的任务，调度这些任务。按照我之前的经验，会把整个系统分为 1）外部通信模块 2）任务调度模块 3）界面模块 4）数据库模块（包含所有表的读写，修改等，提供结构给其他模块）还有其他模块，这里就不说了。 当然这个是我做C的经验来的，我更倾向于按照逻辑功能划分模块。
但是我们有之前做web开发过来的同事，他认为不应该把对各个数据表的处理放到一个数据库模块里。 应该根据数据表建立模块，或者说重新规划一下数据表，将数据表的处理放到每个模块里。每个模块使用三层架构，每个模块对其他模块提供数据表的处理结构（当然每个模块也有自身的处理逻辑）。 这块是我比较难以理解的地方，我还是觉得他说的结构肯能是面向数据的处理架构，特别是web开发，感觉不适合我们的这个系统。
我也找了三层结构的资料看了下，我觉得如果用三层架构，应该是整个系统分成三层架构吧，比如第一层UI层，第二层各个逻辑处理，任务调度，通信等 第三层数据处理，跟数据库交互。不应该是每个模块三层架构吧。这块我还真没经验。 如果说把数据表的处理分散到每个模块处理，比如数据库切换了，那岂不是每个模块都要修改一下。
以专业开发人员为伍 2018-05-13
其实这里的关键不在于你适不适合分为三层，而是你满脑子只有数据库表增删改查，没有把精力搞懂三层。
你所说的整体只有 DAL，那么很可能地，BLL对于你来说所理解的只是薄薄的一层当作等价与 DAL 的东西，而表现层更是满脑子只有类似于 SQL Server 客户端管理器那样的一个左边是表格树右边是GridData 的东西，剩下的就没有什么了。
所以放下这种为了三层而三层的思路，才能真正搞懂网络软件三层架构。
以专业开发人员为伍 2018-05-13
完全没有必要纠结什么 DAL 问题。你在 BLL 中使用 ADO.NET 或者 EF 之类的来直接操作数据库就可以了，不要把大量时间仍在去封装 DAL 这种事情上。
真正要花时间的，首先是前端，其次是 BLL。这两部分层次代码要花掉95%以上的开发时间。你见到有人整天纠结 DAL，这就好像一个人要开发软件之前先要自己开发一个数据库系统、磁盘管理系统一样，那时间都浪费到最底层的、人人都在刚学编程时就接触的底层上了。
xuzuning 2018-05-13
一层层的包裹起来，很有点作茧自缚的味道，典型 Java 的做派
xuzuning 2018-05-13
其实真的不必要 三层，MVC 最容易弄
现在不也流行多中心吗？什么数据中心、控制中心、.....
stevenjin 2018-05-13
根据需要选择吧，不用架构小巧而快速。但大项目最好用架构。什么 系统与三层什么的并没有关系。
如果你会用到多种数据库的话，用基于接口的方式比较好切换。
