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