【问题标题】:Dynamics CRM deployment: manage solution components dependenciesDynamics CRM 部署:管理解决方案组件依赖项
【发布时间】:2016-02-09 11:29:44
【问题描述】:

我们正在尝试创建 Dynamics CRM 解决方案(在线版),遵循 microsoft - ALM best practices 中的一些指南。其中一项建议是创建一个核心实体解决方案,并将托管层和功能作为单独的解决方案置于顶层。

当我们创建一个像“帐户反馈”这样的实体时 - 它取决于帐户 - 它完全适合该层。但是,如果我们想将帐户表单中的所有反馈列为子网格,那么我们正在从帐户 -> 帐户反馈构建依赖关系。这迫使我们将帐户反馈功能移至核心解决方案。如果这种情况继续下去,并且我们在实体之间建立越来越多的依赖关系,我们最终会将所有内容都转移到一个大的单一解决方案中。

我们在这里做错了什么?

【问题讨论】:

  • 您可能会在programmers.stackexchange.com 上获得更多帮助,因为它们更适合此类概念设计问题。
  • 谢谢。我也会在那里发布。

标签: dynamics-crm


【解决方案1】:

你没有做错任何事。只要接受,例如实体帐户可能是您核心的一部分。

核心解决方案通常包含您的数据模型的很大一部分,其实体所需的网络资源也是该解决方案的必要部分。

我建议部署您的核心解决方案,其中仅包含非托管实体。其他解决方案,包含工作流、插件程序集和步骤等,可以单独部署在托管解决方案中。

在一定程度上,您可能会发现将实体模型拆分为单独的解决方案很有用。当您这样做时,您可以在这些解决方案上分发相同的核心实体,或者决定将您的核心实体添加到基础解决方案中。

在第二种情况下,安装基础解决方案是成功安装其他解决方案的必要条件。

【讨论】:

  • 这使得我实例中的所有实体都进入核心,其余的自定义功能进入一个新包。非托管实体不会成为升级问题吗?
  • 非托管为您提供更大的灵活性。托管解决方案最初在设计时考虑了 ISV 附加组件。附加组件的要求是能够卸载它们而不留下任何痕迹。对于您的公司数据模型扩展,这是相当不利的,因为卸载托管解决方案也可能会删除作为其中一部分的表并破坏其中的数据。此外,当对托管实体的非托管修改以某种方式进入您的生产系统时,无法再导入对相同实体的托管更新。
猜你喜欢
  • 1970-01-01
  • 2012-09-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多