其实不用多说，大家都知道网络上软件系统大致可以分为B/S和C/S结构的。对于C/S结构小可认识不足，只是就个人接触，谈谈项目中实际用到的C/S系统架构。
一般的小型系统：使用的C/S系统，个人觉得谈不上什么架构方面的问题。只是简单的读取数据库，显示到前台而已。一般也就分为两层：服务器端、客户端，所实现的也是胖客户端。服务器上也就是run个数据库。
而当系统规模够大，不谈架构我想就不可能了。个人接触B/S方面的架构也算有一些小小见识，因此觉得其实大型C/S架构也多少在参考着B/S方面的架构，而万变不离“祖宗”的道理。
一个大型C/S架构我想大致可以划分为：实体层/业务逻辑层/用户控件层/前台界面层。
下面逐一分析一下一各个层之间的作用：
实体层（ENTITY）：用于直接与数据库进行交流，其中这些一般会用到代码生成器。直接将数据库中的表名、字段映射到实体层。实体层作用，一般用到批量增、修时候用实体会比较好，因为不用将数据直接与数据库打交道。而当只是一个简单的sql select的时候，我想还是避开实体层的好，要不会得到相反的结果。
业务逻辑层（LOGICAL CONTROL）：如果真正到了仔细考虑架构方面问题的时候，我想此软件系统的业务逻辑也应该不会轻松。必定会让设计人员和开发人员头疼。最好的办法就是把业务逻辑层单拉出来。作为承接作用，定义好接口，供外界调用。我想这和B/S结构的j2ee里的struts的action非常相似。
用户控件层（USER CONTROL）：这一层主要是用来减少开发量，把多处用到的控件抽象出来。以供重复使用。例如把datagrid包装成自己系统需要的，并加一些其他如combo、button等控件，以供开发人员拖拽，大大减少开发量。当然这一部需要在前期工作时候，把设计工作完成好。需要哪一部分抽象出来，可以被多开发用户批量使用的，一定事先弄清楚。
前台界面层（USER FACADE）：这一层就不多说了，相信大家都可以理解，就是form。
最后说一点：把层次之间的依赖关系限定好，如entity不可以调用业务逻辑层…………，以此类推。
热烈欢迎各位拍砖！有说的不恰当地方请指教！谢谢。接下来会写一些B/S方面架构，以及data warehouse的ETL 方面的文章！
