我们在 ASP.NET MVC 中开发了简单的 CRM 应用程序。它适用于用户帐户很少的单一组织。
我正在寻找使其与许多组织合作的简单方法。我可以使用会员提供者的ApplicationId 吗？每个组织都拥有自己的ApplicationId。
但这意味着数据库中的每一行也必须有ApplicationId，对吧？
请给你建议。也许有更好的方法？
【问题讨论】：
标签： c# model-view-controller crm
不幸的是，您已经错过了公共汽车。因为简单的方法是通过设计使这成为可能。将OwnerId 包含到已经在第一阶段的数据中并让您的业务逻辑根据它工作不会有太大的负担。
目前“简单的方法”是重构所有数据和业务逻辑以包含OwnerId。在做的时候，向前看。想想“如果我们将来需要支持这个和那个怎么办”的情况，并通过设计为未来留出一些空间。您现在不需要完全实现所有内容，但您会发现如果您的应用程序被设计为可扩展的，那么让您的应用程序可扩展是多么容易。
ApplicationId 是一个内部 ID，用于确定每个应用程序的会员数据范围。我会避免将这种逻辑渗透到整个应用程序中。请记住，验证您的 Web 用户并为他们分配角色并通过角色赋予他们权利是与数据所有权完全不同的过程。
在 ASP.NET MVC 中，您将使用[Authorize] 属性来确保某些操作可以或不能由某些用户或组执行，同时确定哪些数据属于谁，应该在数据本身中实现。即使您将运行应用程序的两个或更多实例，它仍然是同一个应用程序。所以ApplicationId 不适用于确定数据范围。
但是，假设您的 CRM 将来不会那么小，很明显，您的初始组织或后来的组织之一希望允许他们的客户登录并检查他们的数据，您会需要构建另一个应用程序供客户登录。此站点将使用与您的 CRM 不同的 applicationId。然后您的客户组织可以将用户帐户映射到他们的 CRM 记录，以便他们的客户可以查看它们。
因此，由于您的 CRM （仍然）很小，因此最简单的方法是为您的 clients 设计一个好的架构以存储其中，然后使用 OwnerId 标记您的所有 CRM 数据。而OwnerId 不能来自用户表、会员表或附近的任何地方。它必须来自列出数据合法所有者的表格。无论您想称它们为组织、公司、客户还是其他名称。它不能是userId、roleId、applicationId 等，因为用户可能要离开拥有的组织，所以在组织（至少是用于确定对某些 MVC 操作的访问权限的组织）和@987654333 之间共享角色@ 用于界定不同类型的客户端应用程序之间的成员资格和角色。
因此，您在这里缺少的是描述 CRM 记录所有者并将所有数据映射到其所有者的表格。为此，没有简单的方法。您已经在继续开发 CRM 时认为“这只是一个简单的单一组织 CRM，所以让我们让事情变得简单”。现在你有一个“简单的多组织 CRM”，并要求一种简单的方法来从最初缺乏设计中恢复过来。下一步是问你如何让你的“不那么简单的多组织 CRM”轻松地做一些你没有做的事情一开始就不考虑。
简单的解决方案是设计您的应用程序可扩展并做“一点点”额外的工作以支持未来的增长。从长远来看，这比每年两次花费大量额外的重写应用程序要容易得多。另外，请记住。毕竟这是一个 CRM，你不能继续告诉任何在他们的业务中使用它的人，因为我们正在修复 CRM 中的一些东西，所以他们放假了。
我不是在这里光顾你。我正在回答任何可能正在阅读本文的人，以停止寻找简单的解决方案来从不充分的计划中恢复过来。没有。找一个就是犯同样的错误两次。
取而代之的是，拿一些笔和纸，计划一个可行的设计并让它发挥作用。在软件设计和开发的早期阶段付出一些额外的努力，您会发现这项工作在以后的过程中为您节省了无数小时。这样，任何使用您的 CRM 的人都会乐于使用它。与您的用户讨论未来的变化会变得更容易，而您不必考虑“我不想这样做，因为它会再次破坏应用程序”。相反，您可以一起享受头脑风暴的下一个酷步骤。有些想法会留到以后，但在这个阶段已经设计了一些实施空间，以便一年后的实际实施顺利进行，并使所有相关方都感到愉快。
这是我的简单解决方案。我有 15 年的发展，而且我仍然喜欢它来支持上述内容。这主要是因为我把每一个（无论如何都是大多数）挑战当作一个更好地设计代码的机会，而不是试图躲避不可避免的过程。我们在芬兰有一句老话：“要么做，要么哭”。它完全符合这里的要求。如果你这么喜欢哭，现在就采取“简单的方法”，就看你自己了。
【讨论】：