将 .NET 中的 DAL 设计为“数据源独立”而不仅仅是“数据库独立”?

发布于 2024-10-09 22:44:07 字数 280 浏览 0 评论 0原文

如何设计如此灵活的DAL(特别是在.NET中)?

.NET 提供了哪些接口以及我应该自己做什么?

这是一个以 SQL Server 作为数据源的全新项目,但将来,部分内容将迁移到不同的 NoSQL 类型的数据存储。

此外,我们可能需要尝试许多不同的数据存储(例如某些数据可能必须与 Cassandra 一起使用,一些数据可能必须与 RDBMS 一起使用,一些数据可能必须与其他 DHT 一起使用等)。

因此,需要易于切换的访问层。我现在所知道的只是“数据”和“该数据所需的操作”。

How to design such flexible DAL (specifically in .NET) ?

What interfaces .NET provides and what should be done on my own ?

Its a greenfield project starting with SQL Server as data source but in future, parts of it will move to different NoSQL type of datastores.

Also, we may need to experiment with lot of different datastores (like some data may have to go with Cassandra, some with RDBMS, some to other DHT etc.)

Therefore easily switchable access layer will be needed. All i know right now is the 'data' and 'operations needed on that data'.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

猫九 2024-10-16 22:44:07

很简单:你没有。这与技术无关,而是不同商店之间完全不同的行为特征。

例如,SQL 在查询中确实很出色,任何像样的 DAL 都会以动态方式公开这些查询(即没有“GetCustomerById”函数)。

用 XML 文件替换它将会是可怕的,并且会给 DAL 端带来很大的压力 - 您需要重新实现非常强大的搜索语义,而没有适当的磁盘结构来加速它。

一旦你习惯了正确的关系定理,大多数 NoSQL 数据存储就会变得非常糟糕。它们在行为和功能上没有可比性,因此 DAL 无法在重要的项目中将其抽象出来。

Simply: you do not. Ths is not so much about technology, but about totally different behavioral characteristics between different stores.

For example, SQL really shines in queries, and any decent DAL will expose those in a dynamic fashion (i..e no "GetCustomerById" function).

Replacing this with a XML File will be horrific and put a lot of stress on the DAL side - you need to reimplement a very powerfull search semantics without the proper disc structures to speed it up.

Most NoSQL data stores seriously ysuck once you get used to the proper relational theorem. They are not compareable in behavior and functionality, and as such a DAL can not abstract this away in a nontrivial project.

梦在夏天 2024-10-16 22:44:07

好吧,这是一个有点无聊的问题,但是如果你看看 NHibernate 这样的东西,你可能会得到一些想法。我并不是建议您采用它(或不采用它),但您会看到像这样的成熟框架如何将存储库细节与代码分开。

另外,看看框架如何为 SQL Server 定义连接、命令等。有一个实现 IDbConnection 的 SqlConnection。如果您的代码在 IDbConnection 上运行,您可以自由切换到 oracle 连接(理论上是这样)。

Ok, it's a bit of a fluffy question, but you might get some ideas if you look at something like NHibernate. I'm not suggesting you adopt it (or don't adopt it) but you'll see how a mature framework like that separates repository specifics from the code.

Also, take a look at how the framework defines connections, commands, etc for SQL Server. There's a SqlConnection which implements IDbConnection. If your code then operates on IDbConnection you are free to switch to say an oracle connection (well in theory).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文