2008-09-16 89 views
0

如果我有以下几点:创建多个对象或创建单个对象的几种方法的一种方法?

Public Class Product 
    Public Id As Integer 
    Public Name As String 
    Public AvailableColours As List(Of Colour) 
    Public AvailableSizes As List(Of Size) 
End Class 

,我想从数据库中获取的产品清单,并与他们现有的大小和颜色沿着页面上显示它们,我应该

  1. 有一种方法(GetProducts())使用单个视图来加入相关表,然后循环遍历每行并根据需要创建对象?或...
  2. 有几种方法,只负责每个创建一个对象?例如。的GetProducts(),GetAvailableColoursForProduct(ID)等目前我正在做一个

),但我添加其他的其他属性(多张图片,可选的流苏等)的代码越来越非常杂乱(有检查这是不一样的产品为上一行,具有这种颜色已经被添加,等等),所以我很想用b去)但是,这将真正斜坡上升往返数据库的数量。

回答

1

你可能最好关闭两个基准,并找出。我已经看到仅仅做多个查询(MySQL喜欢这样)的情况比JOIN更快,并且一个大的缓慢查询需要很多内存并导致数据库服务器发生颠簸。我说基准测试是因为它将取决于您的数据库服务器,它具有多少内存和并发连接,表的大小,索引如何优化以及典型记录集的大小。在大型未指定索引的列上联接非常昂贵(因此,您不应该执行它们或添加索引)。

如果你至少写了两个实现(你不需要编写方法,只是一堆测试查询),然后基准测试,你可能还会学到更多/更满意的东西,而不是只与其中一方去。最棘手的(但重要的)测试部分是模拟并发用户同时击中数据库 - 实际的生产内存和CPU负载。

请记住你是在处理2个问题:一个是DBA的问题,我怎么让它最快和最有效。第二个是程序员,他们想要漂亮的,可维护的代码。 (b)使您的代码更具可读性和可扩展性,而不仅仅是具有复杂JOIN的巨大查询,所以您可以决定在(a)中优先考虑它,只要它不会太慢。

0

就个人而言,我会得到通过较少的方法更多的数据库数据,然后绑定只针对我目前想显示这些数据集的部分UI。处理大量的小数据块来获得特定的数据块比拿出大块数据块和仅使用那些你需要的数据块要困难得多。

1

你明白了。解决方案b不会扩展,所以解决方案a是关键,只要性能受到关注。同时,为什么要限制GetProductDetails()方法来获取单个请求中的每个数据(因此是SQL视图方法)?为什么不能有此方法进行3个请求,并说再见你凌乱的逻辑:

  • 一个用于标识和名称检索
  • 一个用于颜色列表
  • 一个用于尺寸列表

根据在您使用的SQL引擎上,这3个请求可以分组在单个批量查询中(一次往返),或者需要3次重复行程。向班级添加其他属性时,您必须决定是增强第一个请求还是增加一个新的。

+0

干杯。对不起,我应该稍微清楚些。我希望GetProductDetails获取产品列表,而不仅仅是一个,因此在里面有三个请求不起作用。将编辑我的问题。 – jammus 2008-09-16 12:21:10

0

在上述情况下,我可能只是有一个单一的静态加载方法,特别是如果所有或大多数的属性,通常需要:

Public static function Load(Id as integer) as Product 

Product.Load(Id) 

如果说颜色属性rarly使用,相当昂贵的加载那么你可能想还是用上面的而不是从那里加载颜色属性,但动态地从吸气加载它,像这样:

private _Colors as list(Of Color) 
public property Colors() as List(Of Color) 
    get 
     if _Colors is nothing 
      . .. . load colors here 
     end if 
    end get. . . . . 
0

转到了选项b)它使你的属性独立于数据的呈现(如桌子)

我认为你会从更多地了解MVC-Architecture受益。它代表M odel(您的数据 - >产品),V查看(演示 - >表格)和C ontroller(一个新类,将从模型中收集数据并对其进行处理以查看输出)

困惑?这并不复杂。您的代码段来自哪种语言?像Ruby on Rails,Java Struts或CakePHP这样的许多框架实践了程序层的这种分离。

0

B.将更快(性能明智),而读您的设置,但它需要你更多的维护代码的时候,你会更新类(更新每个功能)。

现在,如果性能是你真正的目标,只是基准它。写出a和b,加载你的数据库几(几百)千记录和测试。然后选择你的最佳解决方案:)

/维伊

0

如果你使用任何敏捷租户在那么你的编码实践“一”是罚款,但现在为您的查询的复杂性的增长,你应该考虑重构,即build你的代码基于你现在知道的,并在必要时重构。

如果重构我建议引入factory pattern到您的代码。工厂模式管理复杂对象的创建,并允许您从消耗对象的代码(在这种情况下为您的UI)隐藏对象构造的细节。这也意味着,随着您的对象变得越来越复杂,消费者将免受可能需要进行的管理复杂性的变更。

0

你应该看看Castle的ActiveRecord ORM,它工作在NHibernate之上。您开发了一个数据模型(就像您使用'产品'所做的那样),它继承了AR的基类,这提供了很好的查询能力。 AR/NHibernate提供积极的查询优化和缓存。性能和可伸缩性问题可能会消失。至少你有一个体面的框架来调整。你可以很容易分开你的数据模型来测试B.

相关问题