嘻嘻，想不到pcplayer兄还在这里混呀。
列位看官，用二层还是三层/多层或者是完全B/S的其实都行。具体得看应用来。
二层的优点：开发较简单，直接，程序逻辑容易理解，维护也容易。
三层/多层的优点：前端程序并不关心后端的数据存储模式，只专注于程序界面与程序录入逻辑，它的优点是在于架构上的。如果你已经确实地知道了（并且不会改变）数据存储方式与网络架构，那么，其实，多层的优点并不会比二层多出多少，照我看，怕只是多出了一个容易控制客户端数量与行为的优点吧。
纯B/S优点：零客户端维护。管它什么网络，一律http、统一html。
那么，来看一看缺点，
C/S 程序，在程序设计与开发阶段就要仔细考虑并确定数据库存储的方式，网络的架构，一旦决定，开发倒也没有太大的难度，如果不同的子网间要同步数据，只需要制订RDBMS的同步计划。程序开发完成后，如果数据库存储方式(比如Oracle太贵，最后终于买了InterBase)或者网络架构(比如客户端与服务端突然加了个防火墙而且突然有个变态网管将其设定成只允许走http@80端口
~~~~~ 等等 )突然有变化，那么，将给你带来一场恶梦。
多层方式中，显然，程序设计难度突然增加了许多，程序员突然加重了许多工作，整天为DCOM线程问题、连接方式问题、负荷问题而忧心仲仲，继而开始发现白发增多，女朋友也开始埋怨说陪她的时间太少~~~~~~~~~ 但是，离开发结束还有二周多时间的某一天，老板突然带着一副好象被霜打了的茄子般的脸孔召集开发会议说：“客户突然选用了另一种数据库产品，可离交货期只有二周了~~~~~” 只见你轻轻地从嘴边泛起一个自信的微笑，很平静地说道：“没问题。” 此时的你，一定会觉得前面的路走对了。
事实上，从程序编写者的角度来看，要写好一个多层的程序，其难度大约要比一个C/S程序高出三个数量级。因为，要从根本上转变思路，以多线程，最小数据量等网络编程方式处理与解决问题，也不要盲目地使用书本上的示例，必须专注于为每一个应用程序服务器提高性能，不要使用Select * from Table这样的语句，要多多利用RDBMS本身的优点，永远记住最小数据量与最短加锁时间。在客户端程序中，也尽量不要去考虑数据存储的方式，尽量减少网络数据传输量，共用的逻辑功能在应用程序服务器完成。程序完成后至少做三次代码的ReView。
纯 B/S 方式显然是最灵活的，但是，就算是有基于IE的强大的DHTML的支持，在客户端的表现力上，仍然是没法做到良好的使用性，特别是海量数据录入与打印。
那么，对于fjw来说，最好的方式是什么呢？其实，在我看来，也没有什么最好的方式，只有最适合的方式。
1 如果使用C/S方式，刚每个子网内部使用C/S方式 ，子网间直接用 RDBMS的数据同步机制。
2 如果用Client/AppServer/Server方式，当然是DataSnap，至于连接方式，用DCOM或者Socket都行，如果要我说，干脆使用 RemObjects SDK ，它是一个使用HTTP的DataSnap技术，其应用程序服务事实上就是一个HTTP Server。
3 如果用B/S，建议将数据录入部分与打印部分单独做成应用程序。通讯方式仍然使用HTTP。 可以使用XMLHTTP。
事实上，还是要看你的开发人员对技术架构的熟悉程序。先做十拿九稳的事儿。有空了再Upgrade。
