使用 LINQ 表达式或规范模式访问 Ingres 数据库?

发布于 2024-11-17 19:11:10 字数 1101 浏览 2 评论 0原文

我正在开发一个 WCF 项目,该项目提供来自多个数据源的业务信息。为了重用代码,我的 BusinessContactService 包含一个通用存储库依赖项,定义为:

public interface IRepository<T> {
   IQueryable<T> Find(Expression<Func<T, bool>> criteria);
} 

服务通过存储库查询数据源:

repo.Find(b => b.Name.Contains("abc"));

当数据源是 sql server 数据库时,它通过实体框架工作。但是,当该服务在 Ingres 数据库上运行时,就会出现问题,因为其 .NET 数据提供程序或 ODBC 驱动程序无法使用 LINQ 表达式。以下是我发现的一些解决方法:

  1. Virtuoso 数据提供程序 EF:因为它不是免费的,而且系统团队也不想安装它,所以我无法使用它。
  2. 自定义 Ingres EF 提供程序,如实体框架示例提供程序所示。这很有趣,但我担心不会制定时间表(下周之前!)
  3. 通过使用规范模式隐藏我的服务中 LINQ 表达式的使用。因此在sql server规范实现中仍然使用LINQ,而对于Ingres案例则使用ado.net。
  4. NHibernate.Linq。我对NHibernate知之甚少,但是这里有人说它与ODBC一起工作得很好并且我想它可能能够将 LINQ 表达式与 Ingres 桥接起来。

请对选项2-4提出建议。非常感谢!

I am working on a WCF project, which provides business information out of several data sources. To reuse the code, my BusinessContactService contains a generic repository dependency defined as:

public interface IRepository<T> {
   IQueryable<T> Find(Expression<Func<T, bool>> criteria);
} 

And service queries data source via repository as:

repo.Find(b => b.Name.Contains("abc"));

When the data source is a sql server database, it works via Entity Framework. But when the service runs on an Ingres database, it comes a problem because its .NET data provider or ODBC driver doesn't work with LINQ expression. The following are some workarounds I've found:

  1. Virtuoso data provider for EF: As it isn't free and system team don't feel like install it anyway, I can't use it.
  2. Customize an Ingres EF provider as Entity Framework sample provider shows. It is quite interesting, but I am afraid not make the timeline (by next week!)
  3. Hiding the usage of LINQ expression in my service by using specification pattern. Therefore still use LINQ in sql server specifications implementation, while use ado.net for Ingres case.
  4. NHibernate.Linq. I know little on NHibernate, but someone here said it works fine with ODBC and I guess it may be able to bridge LINQ expression with Ingres.

Please give suggestions on option 2 - 4. Many Thanks!

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

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

发布评论

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

评论(1

小苏打饼 2024-11-24 19:11:10

首先,提一个小建议。对于您的通用接口,我认为最好公开:

IQueryable<T> Query<T>();

因此应用程序层将能够调用它并链接它想要的任何内容,例如:

var temp = repo.Query<User>().Where(c => c.Email.Contains("@foo.com")).OrderBy(c => c.FirstName);

对于您的问题,我发现,当没有 EF 提供程序时 -或者您因任何原因无法使用它 - NHibernate 和 Fluent Nhibernate 是不错的选择。不如 EF 强大(显然是代码优先),但仍然是一个很好的后备方案。它支持最常见的 linq 运算符,并且非常适合您的抽象设计。

First of all, a little suggestion. For your generic interfece, I think it would be better to expose:

IQueryable<T> Query<T>();

So the application layer will be able to call it and chain whatever it wants, like:

var temp = repo.Query<User>().Where(c => c.Email.Contains("@foo.com")).OrderBy(c => c.FirstName);

For your question, I found out that, when there isn't an EF provider - or you can't use it for any reason - NHibernate with Fluent Nhibernate are quite the alternative. Not as powerful as EF (code first, obviously) but still a good fallback. It supports the most common linq operators and it will fit perfectly in your abstracted design.

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