随想：把SQL Server 2005当Class容器

一、问题产生与需求简述：

公司一直使用在delphi开发erp系统的app(midas)，虽然在该app.exe中，有分离成两个部分：Class管理器+业务Class，但一直苦于有以下3类需求难以实现：

1.执行过程中，想更换业务Class难以实现(俗称热插拔)，一般只有重启App.exe；

2.执行时间长的业务不好处理，执行过程中，前台除了伪进度条外，难有实时反馈；

3.业务Class很多，若某个Class设计不良而出现内存泄露，整个app.exe会死掉；

二、选择JBoss(J2EE)还是IIS(c#.net)作为Class容器如何？

如上所述，这迫使我必须追寻新的app框架，如果不考虑成本因素，满足以上几个条件的最好选择是J2EE的各类EJB容器(如JBoss等)。但J2EE的开发成本实在太高了，有没有其它低成本的解决方案呢？

比如说使用c#.Net可否？c#是借鉴了大量Java的经验开发出来的，其书面规格是可以满足上述要求，同时开发成本(包括人资与时间)也最低。但经过自己一段时间的测试，后来发现.Net的最大问题是稳定性，或者说IIS作为.Net的Class容器，实在还不够成熟，而市场上并没有发现成熟的知名的.Net容器。而且另一个问题是，作为c#.Net的推荐标准Web Service，其传输使用的xml格式，这在遇到大数据量(如报表)需在在Internet上传递时，将会有很大的性能问题。

只有选择J2EE？J2EE的优点地球人都知道，这只能是最后的选择(不幸言中)，但明显缺点就是开发成本过高，还有已存在的Delphi产品如何平滑过渡都要考虑。

难道我一定要选择成本最高的J2EE吗？

三、选择SQL Server 2005 Express作为Class容器如何？

回思所谓的三层架构(T/S)，app主机主要是两个部分：Class容器+业务Class。

SQL Server本身可以执行SQL Procedure，若把SQL Procedure看成业务Class，那么SQL Server就是一个优秀的Class容器喔：1.稳定够；2.支援事务(能不支援吗)；3.可热插拔； 4.不存在数据传输效率问题；

看到此处，会不会有人说，把业务逻辑放在SQL Server内，那DB主机能负载几个用户？这不是回到了传统的C/S模式吗？C/S在遇到大量并发用户时就玩完了...

呵呵，莫着急，性能的问题可以透过负载平衡来解决，连接方式如下(CSDN不知如何传图片，只有以文字描述)：

Client主机 --(广域网)--> AP主机(SQL Server 2005 Express) --(局域网)--> DB主机(SQL Server 2005 Enterprise)

看出来没有？存放业务Class的AP主机是安装的SQL Server 2005 Express(这是一个免费版本喔)，该AP主机上存放的只有业务Class即SQL Procedure(以下简称SqlApp)，系统的实际物理数据还是放在DB主机中。依此结构，在用户数多时，随时可以视需要增加新的SqlApp，以解决负载均载问题。而SqlApp与DB主机相连，在SQL Server对SQL Server的网络中，你还担心数据传输性能吗？

四、结束语：

使用SQL Server作为Class容器，最大的问题是SQL Procedure使用的是”SQL语言”。该语言是面向过程而不是面向对象的，但若我们有了面向对象的思想，用什么语言就不是最重要的(也很重要)。

而且，由于是在SQL Server中运行业务Class，只要控制好命名规则，还可以把SqlApp当成一个临时数据存放地，至于其它注意事项，我就不再多述了。

不过呢，为了市场与未来发展需要，我最终还是没有选择此方案，而是选择走上J2EE的不归路。

但这一段思考的过程，特地存底以做留念，也欢迎看到本文的朋友，与我交流，谢谢！

===================================================================================
广告：本人在CSDN上开了个群组：制造业ERP讨论组(网址：[url=http://groups.csdn.net/ERP2008]http://groups.csdn.net/ERP2008[/url] )
若我的资料对你有帮助，请帮忙捧场加入此群组，在该组中的技术问题，我会以更快的时间回复。