本文介绍了数据集到 POCO - 关于 DAL 架构的查询的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我必须非常快速地开发一个相当大的 ASP.NET MVC 项目,并且我想就我的 DAL 设计获得一些意见,以确保没有任何事情会再次困扰我,因为 BL 可能会变得相当复杂.一点背景知识:我正在使用 Oracle 后端,所以内置的 LINQ to SQL 已经出来了;我还需要使用生产级库,因此 Oracle EF 提供程序项目已退出;最后,我无法使用任何 GPL 或 LGPL 代码(Apache、MS-PL、BSD 都可以),所以 NHibernate/Castle 项目退出了.我宁愿——如果可能的话——避免花钱,但我更关心实施正确的解决方案.总而言之,有我的要求:

I have to develop a fairly large ASP.NET MVC project very quickly and I would like to get some opinions on my DAL design to make sure nothing will come back to bite me since the BL is likely to get pretty complex. A bit of background: I am working with an Oracle backend so the built-in LINQ to SQL is out; I also need to use production-level libraries so the Oracle EF provider project is out; finally, I am unable to use any GPL or LGPL code (Apache, MS-PL, BSD are okay) so NHibernate/Castle Project are out. I would prefer - if at all possible - to avoid dishing out money but I am more concerned about implementing the right solution. To summarize, there are my requirements:

  1. Oracle 后端
  2. 快速发展
  3. (L)无 GPL

  1. Oracle backend
  2. Rapid development
  3. (L)GPL-free

免费

我对 DataSets 相当满意,但我会受益于使用 POCO 作为 DataSets 和视图之间的中介.谁知道呢,也许在某个时候会出现另一个 DAL 解决方案,我会抽出时间将其关闭(是的,对).因此,虽然我可以使用 LINQ 将我的 DataSet 转换为 IQueryable,但我希望有一个通用的解决方案,这样我就不必为每个类编写自定义查询.

I'm reasonably happy with DataSets but I would benefit from using POCOs as an intermediary between DataSets and views. Who knows, maybe at some point another DAL solution will show up and I will get the time to switch it out (yeah, right). So, while I could use LINQ to convert my DataSets to IQueryable, I would like to have a generic solution so I don't have to write a custom query for each class.

我现在正在修改反射,但同时我有两个问题:

I'm tinkering with reflection right now, but in the meantime I have two questions:

  1. 此解决方案是否存在我忽略的问题?
  2. 您是否推荐其他方法将 DataSet 转换为 POCO?

提前致谢.

推荐答案

没有正确的答案,尽管你会找到会尝试给你答案的人.需要记住的一些事项:

There's no correct answer, though you'll find people who will try to give you one. Some things to keep in mind:

  • 既然无法获得EF或Linq-to-SQL的优势,那就不用担心使用IQuerable接口了;你不会得到它的主要优势.当然,一旦你有了 pocos,LINQ to object 将是处理它们的好方法!您的许多存储库方法将返回 IQueryable<yourType>.

只要你有一个好的 repository 来返回你的 pocos,使用填写它们的反射是 一个好的策略,一开始.如果您有一个封装良好的存储库,我再说一遍.以后你总是可以切换出反射填充的实体对象代码以获得更高效的代码,而你的 BL 不会知道其中的区别.如果你让自己依赖直接反射(不是 优化反射 像 nHibernate),你以后可能会后悔效率低下.

As long as you have a good repository to return your pocos, using reflection to fill them out is a good strategy, at first. If you have a well-encapsulated repository, I say again. You can always switch out the reflection-filled entity object code for more efficient code later, and nothing in you BL will know the difference. If you make yourself dependent on straight reflection (not optimized reflection like nHibernate), you might regret the inefficiency later.

我建议查看 T4 模板.几个月前,我第一次从 T4 模板生成了实体类(以及用于填充它们并保存它们的所有代码).我被卖了!我的 T4 模板中的代码在第一次尝试时非常糟糕,但它输出了一些不错、一致的代码.

I would suggest looking into T4 templates. I generated entity classes (and all the code to populate them, and persist them) from T4 templates a few months ago, for the first time. I'm sold! My code in my T4 template is pretty horrible this first try, but it spits out some nice, consistent code.

您必须为您的存储库方法制定计划,并密切监控您的团队创建的所有方法.你不能有一个通用的 .GetOrders() 方法,因为它每次都会得到 all 客户,然后你的 LINQ to object 看起来不错,但会覆盖一些不良数据访问!有 .GetOrderById(int OrderID).GetOrderByCustomer(int CustomerID) 等方法.确保每个返回实体的方法至少在数据库中使用索引.如果基本查询返回 一些 被浪费的记录,那很好,但它不能进行表扫描并返回 数千 条被浪费的记录.

You will have to have a plan for your repository methods, and closely monitor all the methods your team creates. You can't have a general .GetOrders() method, because it will get all the customers every time, and then your LINQ to object will look nice, but will be covering some bad data access! Have methods like .GetOrderById(int OrderID) and .GetOrderByCustomer(int CustomerID). Make sure each method that returns entities uses an index at least in the DB. If the basic query returns some wasted records, that's fine, but it can't do table scans and return thousands of wasted records.

一个例子:

var Order = From O in rOrders.GetOrderByCustomer(CustID)
            Where O.OrderDate > PromoBeginDate
            Select O

在此示例中,将检索客户的所有订单,以获取 一些 订单.但是不会有很大的浪费,CustomerID当然应该是Orders上的一个索引字段.您必须决定这是否可以接受,或者是否将日期区别添加到您的存储库中,无论是作为新方法还是重载其他方法.没有捷径可走.您已经在效率和维护数据抽象之间徘徊.您不希望在您的存储库中为整个解决方案中的每一个数据查询都提供一个方法.

In this example, all the Order for a customer would be retrieved, just to get some of the orders. But there won't be a huge amount of waste, and CustomerID should certainly be an indexed field on Orders. You have to decide whether this is acceptable, or whether to add a date distinction to your repository, either as a new method or with overloading other methods. There's no shortcut to this; you have walk the line between efficiency and maintaining your data abstraction. You don't want to have a method in your repository for every single data inquiry in your entire solution.

我发现一些最近的文章,人们正在努力解决如何做到这一点.:

Some recent articles I've found where people are wrestling with how exactly to do this.:

这篇关于数据集到 POCO - 关于 DAL 架构的查询的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

05-18 06:31