我在同一个解决方案中有两个项目，我想知道在AMS和Asp.Net网站之间共享数据库的理想方式是什么。此外，由于它们都使用某种实体框架，我发现在项目之间保持模型同步很难。
想法1：简单地让它们使用相同的连接字符串；但是，如果我在一个项目中使用了代码优先迁移，而另一个项目由于迁移历史落后而无法更新，该怎么办？
想法2：不要让Asp.Net网站接触数据库；让它通过HTTP请求与AMS通信；但这会增加通信的额外网络开销吗？
想法3：创建一个单独的项目，包含所有的实体框架类和DbContext，并让两个项目都引用它。但由于AMS项目需要EntityData类而不是POCO，这给我在其他项目中重用模型类带来了难以想象的麻烦。一旦我安装了所有的移动服务nuget包，我就不能让网站启动。
有什么想法吗？
关于您的问题的一些想法，
想法1：当你准备EF迁移时，会给你带来麻烦。每个项目中的模型最终可能会有所不同，EF不会喜欢这样。最好远离此解决方案。
想法3：是我倾向于在使用量不太大、代码库不频繁更新的项目中使用的。创建一个包含所有EF上下文和迁移的单个数据层项目，然后在多个域层或前端层中引用此数据层。这样做效果很好，可以让事情变得简单。移动服务通过RESTful API公开数据库实体，所以不会有太多麻烦。网站应使用DTO和视图模型在层之间移动数据。我对这个解决方案唯一的问题是，当你更新一个项目中的EF模型时，你还必须更新并发布第二个项目，因为EF模型会发生变化。为了解决这个问题，我自动化了构建和发布过程，只是为了让这个过程更容易管理。请考虑您的解决方案的使用寿命，您可能会遇到项目数据模型出现分歧，最终在一个数据库中有两个数据模型的情况。当你不得不随身携带数据时，稍后将论文拆分为两个数据库可能会非常痛苦。
想法2：在更复杂的情况下，我正在处理大型项目，并不断更新代码库，而该项目将持续到可预见的未来，最好使用一个接口（不会经常更改）来分离这两个服务，并消除对共享数据库的直接依赖。你可以按照你的建议将数据存储在AMS中，然后通过网站上的REST请求访问它。流量可能会增长，以后可能会成为一个问题，这取决于您的网站和移动服务的需求，这可能会减慢您对网站的响应时间。尽管最初，我担心的是对您的网站的响应时间，从网站到移动服务接口再到数据库的多次跳跃。尽管您应该能够通过缓存读取数据而不是写入数据来减轻这种影响。
在您的情况下，为了简化部署，我要做的是将网站和移动服务合并到一个解决方案中，并将合并后的网站和API一起单独托管在Azure网站上，共享包含EF的一个数据层。因此，如果不必使用移动服务，请不要使用，当然这取决于要求。ASP.NET可以在同一屋檐下很好地支持这两种功能。这有点超出了你的问题范围，但对于你眼前的问题来说，这可能是有用的。