方案1、“ASP.NET 应用”+ SQL2K
方案2、“ASP.NET 应用”+“ASP.NET 服务”+ SQL2K
我感觉OA的业务逻辑不复杂，直接把所有的代码写在“ASP.NET 应用”中，不想再去搞 “ASP.NET 服务”？
请大家说说你们通是哪种方案，说说理由！
OA系统对速度要求很高，应将一些运算和复杂查询通过过程和触发器封装在SQL-SERVER中，再设计一个COM来封装对数据库操作和商业逻辑，在COM中用一个代理类，最后提供一个接口供前台调，这样COM活在MTS中，而用户不需要生成很多实例，只与一个接口调用，这样前台压力小了，性能可大大提可，也可扩展。
第一种方案适用于局域网内部得oa系统。
第二种方案适用于广域网范围内得oa系统。
asp.netWeb服务适用于远程的，广域网上的多用户服务，并可进行2次开发，如果是近程的中间组件技术，可以使用Remoting来实现。
而第一种方案是简单的多层结构，在用户比较少，数据量不大的情况下比较合适。
ASP.NET Application + SQL2K + MSMQ + File System
C#(WINFORM) + WEB SERVICE + SQL2K
俺有现成的asp.net + sql + msmq + file system做的OA系统。现在广东联通用得正欢着啦。要不要。买给你。可不便宜哦：）里面涉及到的技术多着啦。
把业务逻辑单独的进行封装，使得系统的扩展性得到提高，如果把业务逻辑放到前台处理使其和前台耦合以后维护起来是很麻烦的。比如，你现在的业务逻辑可以应付目前的需要，但是如果业务逻辑要进行修改你怎么办？还得把前台的东西一起拿出来进行修改，是不是很烦？如果你把业务逻辑单独封装后就会避免这样的麻烦。当然，如果对业务逻辑进行单独封装会使得开发周期增加，看法难度加大。如何取舍就看你的了！！
:-)
