一个客户端程序的架构问题

[narvit]

现在正在设计一个WINFORM的客户端程序,部署在一个工厂里,峰值的时候,估计同时有1000个程序同时运行访问数据库.

程序和数据库交互平率非常高,每个客户端的业务清单是用反射加载DLL到JOB中的,至于加载哪些DLL要看后台配置.
而且这些JOB需要非常快速地完成业务逻辑,比如校验物料,读取设备数据并存入数据库这些工作.
并且需要考虑连接池管理,并发数和后续负载均衡的扩充.

目前的想法是:

把业务层,数据访问层,全部放到WCF里,客户端从业务层拿JSON对象再转成实体.
这样做很标准,也方便后续客户端的迁移.
但是总感觉这样做对客户端PC的性能浪费太大了,而且代码量太大,怕影响性能.

还有一个想法是:
只把数据访问层放到WCF上,业务层,实例层全在客户端上,后续做故障转移,读写分离,就很方便,直接改入口代码就好了.
但是这样又让客户端非常臃肿.

不知道有没有哪位做过类似的开发,给点意见.

[以专业开发人员为伍]

你是不是不小心把上下文写反了呢？！ 假设你在淘宝上买商品，你选中商品然后下单、支付，一切手续在15秒钟之内就OK了。你说这“对性能浪费太大、怕影响性能”，于是你偏要将每一个淘宝订购交易背后将近200个任务都用客户自己去花3个月去做（而不是15秒钟），不让淘宝服务器去做高级的事情（只能做最低级的事情），这样做代码量就小了？性能就好了？ 另外，服务器的高级的业务api不要了，只有最低级的数据库“增删改查”，那么你能真正方便、清楚地控制权限系统吗？ 服务端隔离底层操作，才能做到方便地对底层重构。怎么会说把底层的东西当作高层而推给前台，反而是方便了改进了呢？ 实际上，你满脑子只有底层的增删改查，所以总想多一点标题党，而少一些技术付出。就像有的人发现越是进行分层和协作、越是让前端只做前端（而跟数据库、繁琐SOA隔离，只接触开放的api层）越强大，而你总是跟前者的工程组织对着干，别人用鼠标点点拖拉而你总想敲打命令行，总想把身边的人变成满脑子只塞着最低级技术然后这些人坐在一起都只是从最低级的编程开始做起。

[以专业开发人员为伍]

你想让前端都从最低级的东西开始拼凑起，这样你就觉得“很高效、很节省PC、代码量小、更方便去学习使用”故障转移,读写分离“这类词儿，（自己）改起来方便。 实际上，这都是缺少组织，不追求团队的效果，而只追求个人需求。

[narvit]

谢谢大神的意见,但是实际上这个项目是我一个人做的,所以我更多的是在想怎么才能更快,而不是其他.

[narvit]

而且我为什么会说做业务隔离影响性能,主要是出于并发的考虑,如果WCF不处理细节业务,只负责数据读写,当然就能更快地关闭连接. 和大侠所说的我那些自私的小算盘,根本搭不上边,我们这都是小项目,服务器性能都很一般.

[xuzuning]

一个人依次开发各个功能，和一个团队同时开发各个功能，并没有本质的区别 并不因为是个人开发，就可无视系统工程的规范