OrganizationServiceContext的生存期 - CRM Dynamics 2011

这更像是一个非技术问题。OrganizationServiceContext的生存期 - CRM Dynamics 2011

我们打算与Linq一起使用OrganizationServiceContext而不是调用OrganizationServiceProxy。

我的问题是：上下文的生命周期应该是什么？它应该为每个方法实例化一次，还是可以使用单例方法在Web应用程序的整个生命周期中保留它？

优点/缺点是什么？有什么建议？

在此先感谢

来源

2011-06-06 Chaos

你不应该保持周围的web应用程序的生命一个DataContext。应用程序生命周期在您的代码之外进行管理。

当其他用户同时保存时，还有一个关于保存更改的痛苦世界。 Datacontexts应该始终仅在请求的生命周期内进行管理，并且运行保存更改不应该保存处理中的其他人的请求中的碎片。

如果你想减少读取，然后使用缓存。如果要管理具有工作单元的并发使用事务。

来源

2011-06-06 06:01:25 Gats

这是'保存更改'的好处。像大多数其他CRM一样，我们一次至少有20个人使用该系统。感谢盖茨+马特 – Chaos 2011-06-06 22:26:19

只是想知道，每个工作单位或每种方法创建上下文有什么缺点？ – Chaos 2011-06-06 22:26:51

每个工作单元需要多一点工程和更聪明的设计。它的缺点是可能导致复杂的情况，如控制反转（时髦，但要小心，因为线程问题可能会弹出而不知道）。简而言之，工作单元需要更多工程，每种方法的管理更简单，但可能导致意大利面代码和数据库流量的显着增加。没有简单的答案，但对于需要高流量执行的网站，您必须将工作单元视为选项。 – Gats 2011-06-07 00:40:45

只是为了扩大一点Gats的答案，这是完全正确的，我们为每个单独的方法创建了新的上下文对象。即使是Silverlight，我们知道我们一次只为一个用户运行，但为了避免创建新的上下文对象，随时管理上下文中的内容太痛苦了。

来源

2011-06-06 14:20:46 Matt

OrganizationServiceContext的生存期 - CRM Dynamics 2011

回答

相关问题