数据集到POCO - 关于DAL架构的查询

时间:2010-05-17 14:30:24

标签: c# .net asp.net-mvc dataset poco

我必须非常快地开发一个相当大的ASP.NET MVC项目,我想对我的DAL设计有一些看法,以确保没有任何东西可以回来咬我,因为BL很可能变得非常复杂。一点背景:我正在使用Oracle后端,因此内置的LINQ to SQL已经完成;我还需要使用生产级库,因此Oracle EF提供程序项目已经完成;最后,我无法使用任何GPL或LGPL代码(Apache,MS-PL,BSD都没问题)所以NHibernate / Castle项目已经淘汰了。我希望 - 如果可能的话 - 避免抛出钱,但我更关心的是实施正确的解决方案。总而言之,有我的要求:

  1. Oracle后端
  2. 快速发展
  3. (L)GPL - 自由

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

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

    1. 这个解决方案有没有我忽略的问题?
    2. 您建议将DataSet转换为POCO还有其他方法吗?
    3. 提前致谢。

3 个答案:

答案 0 :(得分:3)

没有正确的答案,但您会找到会尝试给您一个的人。要记住的一些事情:

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

  • 只要你有一个好repository来返回你的pocos,首先使用反射来填充它们a good strategy如果你有一个封装良好的存储库,我再说一遍。您总是可以在以后切换出反射填充的实体对象代码以获得更高效的代码,而BL中的任何内容都不会知道其中的差异。如果你让自己依赖进行直接反思(而不是optimized reflection喜欢nHibernate),你可能会后悔效率低下。

  • 我建议调查T4 templates。几个月前,我第一次从T4模板中生成了实体类(以及填充它们的所有代码,并保留它们)。我卖了!我的T4模板中的代码在第一次尝试时非常糟糕,但它会吐出一些漂亮的,一致的代码。

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

一个例子:

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

在此示例中,将检索客户的所有订单,只是为了获得订单的部分。但是不会有大量的浪费,而且CustomerID肯定应该是Orders上的索引字段。您必须确定这是否可接受,或者是否将日期区分添加到存储库,作为新方法或重载其他方法。这没有捷径;你已经在效率和维护数据抽象之间走了一条路。您不希望在整个解决方案中的每个数据查询中都有一个方法存储库。

最近的一些文章我发现人们正在努力解决这个问题。

答案 1 :(得分:2)

Devart dotConnect for Oracle支持实体框架,然后您可以使用LINQ to Entities。

答案 2 :(得分:1)

不要担心使用反射来从数据集构建DTO。他们工作得很好。

痛苦的一个方面是为每个业务对象实现IComparer。仅加载表示层中最低要求的数据。我把手指严重烧在内存排序上。

另外,计划在DTO上进行延迟加载。

我们在Generic库上编写了将datatable / datarow转换为entitycollection / entityobjects的方法。而且他们工作得非常快。