改善nHibernate数据访问层的性能 [英] Improving the performance of an nHibernate Data Access Layer

问题描述

我正在努力改善现有Asp.Net Web应用程序的数据访问层的性能.场景是.

I am working on improving the performance of DataAccess Layer of an existing Asp.Net Web Application. The scenerios are.

1. 它是Asp.Net中基于Web的应用程序.
2. DataAccess层是使用NHibernate 1.2构建的，并作为WCF服务公开.
3. Entity类标记有DataContract.
4. 不使用延迟加载，由于关系的急切获取，内存中没有大量数据库对象被加载.对数据库的命中率也很高.例如，我使用NHProfiler对应用程序进行了概要分析，并且使用主键进行了大约50多次sql调用来加载Entity对象之一.
5. 我也不能更改代码，因为它根本没有NUnit测试用例的现有实时应用程序.

请在这里获得一些建议吗?

Please can I get some suggestions here?

我尝试使用延迟加载，但是问题在于，由于Entity也用作DataContract，因此它会在序列化期间触发延迟加载. 使用DTO对象是一种选择，但这是一个巨大的变化，因为没有实体如此庞大.没有测试用例，这将需要大量的手动测试工作.

EDIT 1: I have tried using Lazy loading but the issue is that since the Entity is also used as DataContract it triggers the lazy loading during Serialization. Using a DTO Objects is an option but that is a huge change as no of Entities are huge. Without the Test cases this will require a huge amount of manual Testing effort.

项目早就写了，没有编写单元测试的灵活性.例如 实体本身包含CRUD操作并使用NHibernate会话.

EDIT 2: The project was written long back with no flexibility to write unit tests. E.g The entity itself contains the CRUD operation and uses NHibernate Session.

class SampleEntity : ICrudOperation
{
   //fields and properties

   public IList<SampleEntity> Update()
    {

       //perform business logic (which can be huge and call the ICrudOperation of 
       //other entities

       ISession session = GetSessionFromSomewhere();
       session.Update(this); 

    }

}

这只是更新的一个示例.大约有400个相互依存的实体.有没有办法为此编写单元测试

This is just an example for Update. And there are around 400 Entities which are interdependent. Is there a way to write unit test for this

推荐答案

建议1

1. 启用延迟加载
2. 使用 风俗 NhibernateDataContractSerializerSurrogate 删除代理之前 通过WCF发送(

1. Enable lazy-loading
2. Use a custom NhibernateDataContractSerializerSurrogate to remove proxies before they're sent via WCF (check out Allan Ritchie's reply here)

这种组合将减少初始SQL连接的数量，并减小对象图的大小.

This combination will reduce the number of initial SQL joins, and reduce the size of your object graph.

但是，这将导致下一个问题:

However, this will lead to the next problem:

您的消费者/客户将无法访问所有数据.他们将需要多次调用服务器以检索子对象/集合.

Your consumers/clients will not have access to all of the data. They will need to make multiple calls to the server to retrieve child objects/collections.

您可以尝试预测将需要哪些子对象/集合(并急于加载它们)，但这可能是一项繁琐的练习.一个更简单的选择是检查空对象/集合(即在使用者处)，然后调用服务器以获取其他数据.

You could try to anticipate which child objects/collections will be needed (and eager load them), but it could be a cumbersome exercise. A simpler option would be to check for null objects/collections (i.e at the consumer), and make the call to the server to fetch additional data.

您的SQL JOIN运行缓慢吗?您可以尝试将 fetch = join 替换为 fetch = select ，然后查看是否可以加快速度.

Are your SQL JOINs slow? You might try replacing fetch=join with fetch=select, and see if that speeds things up.

确定花费在SQL上的时间，而不是通过网络发送数据所需的时间.您可以考虑先压缩对象图，然后再通过网络发送它.

Determine the time being spent in SQL, vs the time taken to send data over the wire. You might consider compressing your object graph before your send it over the wire.

在将对象图返回给使用者之前，用您自己的自定义懒加载代理 交换所有Nhibernate懒代理.您的自定义代理将通过WCF/Web服务延迟加载数据(而不是调用db).在富客户端上使用此技术已经取得了一些成功.

Swap any Nhibernate lazy proxies with your own custom lazy-load proxies, before returning the object graph to the consumer. Your custom proxies will lazy load data over WCF/Web Services (instead of calling the db). I've had some success using this technique on a rich client.

理论上，这应该允许您的客户端代码保持原样. 沿这些线有一个线段.

In theory, this should allow your client code to remain as-is. There's a thread here along those lines.

希望有帮助.

这篇关于改善nHibernate数据访问层的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！