三层架构--很多数据计算过程写到哪里？

[Damon_Code]

如题，公司不是很专业的软件公司，但是鉴于手里这个工作不是很大的工作量，时间不是很着急，本着试一试正规软件开发的流程，想写的正规一点，看网上推荐用三层架构。

软件主要实现流程：
1、从工厂现场生产线读取数据
问题：1.1 我想同时保存采集到的数据到SQL数据库，还要同时把采集到的数据送到软件的数据处理模块进行处理，这个应 该怎么做？我想的是线保存到SQL，在从里面读出来，但是感觉这个方法太笨了。。。


2、对采集到的数据进行计算
问题：2.1 按照三层架构，我觉得应该写到业务层吧，这次实现的主要是一些统计、分析、平方之类的数学的数值计算，但是看网上三层架构的例子，都很简单，没有见到这种例子，难道是单独写成dll什么的，在业务层调用吗？


3、领导要求，要实现一台电脑计算，可以同时有多个客户端的方法，
问题：3.1 从我的理解，我觉得是用C/S模式，网络没搞过，所以不想用B/S，是吗？
3.2 数据传输打算用远程SQL访问可以不？主要是客户端用来定时读取数据，显示数据画图用。
3.3 上面的画图中，主要是winform中画一些柱状图、折线图，请问是用graph画还是用Chart控件之类的？
3.4 如果还有客户端和数据库的交互，是不是必须用网络了，例如SOCKET了？


非软件专业，想尝试着做的专业一点，问题比较琐碎，先谢谢大家的耐心回答！

[全栈极简]

1、socket模块接收到数据就发送给客户端。 2、三层架构（UI-BLL-DAL），你这些需求属于BLL，单独用个类库项目。 3、c/s可以、b/s也可以；数据库可以用sqlserver存取数据，可以远程也可以本地；画图建议用chart控件画；客户端和数据库的交互通过ado.net。

[wanghui0380]

这个通常采用消息队列+ 发布/订阅 采集队列 存储模块订阅他 处理模块同时订阅他 其实这个无关3层，3层基于对象，而这个其实是传统的数据流导向，可以用的东西有RabbitMQ，Reactive Extensions（rx net），TPL datalfow

[wanghui0380]

如果是我设计 可能的设计方式是 采集的数据 先发给rx做的采集消息总线rxBus 数据处理模块订阅rxbus的消息（收到消息后，处理模块可以继续rx也可以dataflow，这两东西本身设计是目标不同，但是完成的功能交叉覆盖，倒是可以互相配合转换） 处理完的消息，可以用RabbitMQ分发给客户机

[threenewbee]

这个和三层没有什么关系了，应该将任务放入队列，让后台作业服务去计算。

[以专业开发人员为伍]

传统的两层式的程序，是前端直接调用数据库驱动，从而没有使用多服务接口的方式来扩展系统。因此所谓“三层架构”，就是说你有一层数据计算服务，不管你用什么方式实现，反正你对前端屏蔽了这些数据服务的底层数据库，这就是准确的“三层”！ “三层架构”其实非常简单直接。许多人满脑子只有DAL，所以他们忽悠DAL，仿佛DAL重要处理多少业务逻辑——而业务逻辑层则只做简单的数据传递——似地。那是13、14年前一些仿 .net 开源小项目 PetShop 式的所谓“三层”。 实际上，你完全不用考虑这么多。只要你的数据服务是一个独立系统，甚至打算扩展授权模块、计费模块，打算对各种前端开放平台能力，那么没人敢再跟你这个系统提“三层”了。因为你这个系统不管怎么看，都有了强大的 BLL 层。 反之，倒是一些刚写点 asp.net 单机（网站）小程序的人，才会过多地去讲“三层架构”要分成多少个目录、多少个文件、各种代码风格的规矩，之类的。

[以专业开发人员为伍]

纠结DAL的人，言必谈“数据库表”，所有操作只有从“增删改查”角度去考虑他才觉得心里有底。 而“三层架构”，其实很简单，就是你先假设数据是“不落地的”，是在网络里可以保存几天、几个月，然后没用了就扔到的。数据库是备份、统计、找回资料的底层机制。但是数据库其实不是你设计一个强大的开放服务平台的思路出发点，而只应该是一个最终实现工具（其中之一）。