构建可使用“插件"的 .Net Web 应用程序的指南数据访问层 [英] Guidelines for build a .Net web application that can use "plug-in" data access layers
问题描述
我正在构建一个应用程序，该应用程序最初将使用 SQLServer 2008 作为 DBMS.我应该如何构建我的应用程序，以便在稍后阶段我可以使用不同的 DBMS，例如Oracle，无需更改我的代码，即仅通过配置.
I'm building an application which will initially use SQLServer 2008 as the DBMS. How should I structure my application so that at a later stage I can use a different DBMS, e.g. Oracle, without changing my code i.e. via configuration only.
我怀疑我的核心应用程序将调用程序集/层中的代码，该程序集/层封装了应用程序运行所需的所有数据库调用.然后该层将调用特定于 DBMS 的层(基于配置)来进行实际的 DB 调用?谁能指出一个明确的例子?
I suspect my core application will call code in an assembly/layer that encapsulates all the database calls required for the application to function. This layer will then call a DBMS-specific layer (based on config) to make the actual DB call? Can anyone point me to a clear example of this?
谢谢！
在下面添加了说明:
我的想法是我可以有多个程序集，例如MyApp、MyApp.Database、MyApp.Database.SQLServer、MyApp.Database.Oracle 等
My thought was that I could have multiple assemblies e.g. MyApp, MyApp.Database, MyApp.Database.SQLServer, MyApp.Database.Oracle, etc.
MyApp 会发出如下调用:
MyApp would make a call like:
DataSet ds = MyApp.Database.GetSomeData();
...看起来像...
public DataSet MyApp.Database.GetSomeData()
{
return GetDataFromDBMS();
}
GetSomeData 是一个通用调用，即 MyApp 需要GetSomeData()"才能执行某些操作.它不在乎数据来自哪里.
GetSomeData is a generic call i.e. MyApp needs "GetSomeData()" in order to do something. It doesn't care where the data is from.
然后，GetDataFromDBMS 将通过配置文件知道调用 MyApp.Database.SQLServer.GetTheData() 或 MyApp.Database.Oracle.GetTheData().这些方法可以执行从每个 DBMS 获取/处理数据所需的任何操作.
Then, GetDataFromDBMS would know, via a configuration file, to call either MyApp.Database.SQLServer.GetTheData() OR MyApp.Database.Oracle.GetTheData(). These methods could do whatever is required to get/process the data from each DBMS.
推荐答案
你应该考虑使用一个为你抽象数据库的 ORM 工具 (nHibernate)，或者定义一组代表你的 DAL 和然后使用 IoC 实现(Ninject、Castle 等)随意换出底层实现，只要它实现了接口即可.
What you should look at doing is either use an ORM tool that abstracts the database for you (nHibernate), or define a set of interfaces that represent your DAL and then use an IoC implementation (Ninject, Castle, etc) to swap out the underlying implementation at will, so long as it implements the interface.
然而，设计一个面向未来的界面(即可以处理与其他数据库一起工作的微妙怪癖)并不简单，因此您最终可能需要进行更改.
However, designing an interface that is future-proof (ie, can cope with subtle quirks of working with other databases) is not simple, so you could end up needing to make changes anyway.
我会按以下顺序做两件事之一:
I'd do one of two things, in this order:
- 检查您是否真的需要更换数据库.
- 沿着 ORM 工具路线走下去，因为已经为您完成了大量的工作.
抽象数据库的一个很好的例子，不一定是 DAL 本身是微软的企业库数据访问应用程序块.
A good example of abstracting a database, not necessarily the DAL per-se is the Enterprise Library Data Access Application Block from Microsoft.
这篇关于构建可使用“插件"的 .Net Web 应用程序的指南数据访问层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
