如何通过ODBC连接Sybase数据库
回复人：shigx 回复时间：2005-4-29 19:22:00
这里提供一个连接sybase的方法，用oledb方式连接，不是通过odbc，可以省去很多麻烦。（sybase应用并不广，要求得解答可不容易，因此，别忘了给我加分哦！呵呵，开一个玩笑。）
前提：计算机上必须安装sybase驱动程序，可以运行sybase光盘上的client工具。
然后，打开dsedit，添加sybase服务器、ip、端口等信息，设置完毕，在对应条目上单击右键选择ping，如果提示sucess，则这部分安装成功。
在vb开发环境中，引用microsoft activeX data objects library
下面是代码：
'打开sybase数据库
Dim adoConn_sybase As ADODB.Connection
Dim sConnstring_sybase AS string
sConnstring_sybase = "Provider=MSDASQL;DRIVER={Sybase System 11};Persist Security Info=False;DSN=;SRVR=服务器名;DB=数据库名;UID=用户名;PWD=用户口令"
Set adoConn_sybase = New ADODB.Connection
adoConn_sybase.Open sConnstring_sybase
......
注意，上面代码中的服务器名就是在dsedit中设置的服务器名。
Microsoft.Practices.EnterpriseLibrary.Data.dll
主要来说就是数据库链接字符串配置利用了 .net 2.0 中 config 文件中，新增的 connectionStrings 配置节，不再像以前那样使用自己的链接字符串配置节。
范例：
下述就是基于 .net 2.0 的 企业库中，数据库应用Block 的一个配置信息
<add name="Connection String" connectionString="Database=Database;Server=(local)\SQLEXPRESS;Integrated Security=SSPI;"
providerName="System.Data.SqlClient" />
说明：
上面我们可以看到
connectionStrings 配置节是 .net 2.0 本身就具有的，我们在这里定义了实际的数据库链接字符串。
我们在configSections 中可以看到，我们新设了一个dataConfiguration配置节，这个节，我们来指定我们默认的数据库。
这样我们就可以在代码中如下创建默认的数据库：
Database db = DatabaseFactory.CreateDatabase();
当然也可以用
Database db = DatabaseFactory.CreateDatabase("Connection String");
后一个传入的参数，为你在配置文件中，定义的数据库链接字符串名字。
另外，在 dataConfiguration 配置节中，可以定义 providerMappings ，这部分跟 GenericDatabase 关系很大，后面Blog 详述。
GenericDatabase 用在没有特别指定用那种数据库的时候，GenericDatabase 可以简单的理解为通用数据库对象。
.net有哪些架构？
最常用的架构是三层架构。
1. UI Tier（User Interface, 用户接口层）
表示层完成向用户展示界面，提供进一步操作的“驱动接口”，例如按钮，并显示结果。
2. Business Tier（商业层）
完成数据加工，提供加工后的数据给表示层，或者数据层。又可以分为 BLL(Business Logic Layer, 商业逻辑)和DAL(Data Access Layer, 数据访问)。DAL负责存取数据，BLL负责对DAL层操作，对数据进行运算和操作。BLL也负责响应表示层的事件。
3. Data Tier（数据层）
完成数据存储功能。可能是数据库、数据源、XML、文本文件等。
这样就把 数据、业务、显示 分开了。UI层只负责显示给用户看，至于数据怎么处理运算，由BLL进行并响应，处理完的数据，怎么存取由DAL层进行，数据怎么存在介质上由Data层完成，DAL就不用管。各层之间相对比较独立，物理依赖性就不那么高了，有时候就只需要编译改动过的层。
一般对开发和设计人员来说，只需要对UI, BLL, DAL 进行设计开发，DATA Tier由OS或者DBMS来进行，你只需要按“格式”来存取数据即可。
“三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题在你的项目里面：
1. UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用, 并且这些语句保证不会修改数据?
2. 如果把UILayer拿掉, 你的项目还能在Interface/API的层次上提供所有功能吗?
3. 你的DAL可以移植到其他类似环境的项目吗?
4. 三个模块, 可以分别运行于不同的服务器吗?
如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则:
1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程
2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式
3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关
4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群
所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了, 完全没必要作的这么复杂. 而多层结构, 是用于解决真正复杂的项目需求的.”
而且三层之间有时候也不用那么严格，得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。
