拆分 EDM 以在多个项目中重用功能
我目前有一个 ASP .NET MVC / EF4 项目，其中包含许多自主功能，例如博客、活动、竞赛、wiki 等。
每个系统使用的实体都通过一个巨大的 EDM 文件映射到我的数据库。
这对于主站点来说效果很好，但我也有一些个人站点，我想在其中重用主站点中的博客功能。
我最大的问题是，由于 mac 老爹 EDM 文件，我的博客网站必须不断更新其数据库模式，以反映对他们不使用的功能区域所做的更改（即对事件系统的更改）。
唯一的其他问题是，有些实体（用户和标签）与每个功能领域的实体有关系，因此很难简单地将每个功能领域拆分为自己的 EDM。
综上所述，我正在尝试找出最有效的方法来设置它。
我是否应该沿着每个领域（博客、活动、竞赛、wiki）拆分 EDM 的道路，并找出一种方法来维护用户和标签实体的关系？
或者我应该为每个网站创建一个 EDM，只映射它实际需要的实体？唯一的问题是我的存储库层接受 UnitOfWork/ObjectContext，并且通过为每个站点创建新的 ObjectContext，我在重用存储库代码时会遇到问题。
I currently have an ASP .NET MVC / EF4 project that contains many pieces of autonomous functionality such as a blogging, events, contests, wiki, etc.
The entities used by each system are all mapped to my database through one giant EDM file.
This works well for the main site, but I also have a few personal sites where I want to reuse just the blogging functionality from the mains ite.
My biggest problem is that due to the mac daddy EDM file, my blog sites have to constantly have their database schemas updated to reflect changes made to areas of functionality that they don't use (i.e. changes to the events system).
The only other gotcha is that there are some entities (Users and Tags) that have relationships with entities from each area of functionality, making it hard to simply split each area of functionality off into its own EDM.
With all of this said, I'm trying to figure out the most efficient way to set this up.
Should I go down the road of splitting up the EDMs by each area (blogs, events, contests, wiki) and figuring out a way to maintain relationships for the User and Tag entities?
Or should I just perhaps be creating an EDM for each website that only maps the entities that it will actually need? The only problem with this is that my repository layer takes in a UnitOfWork/ObjectContext, and by creating new ObjectContexts for each site I'd have problems reusing my repository code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以设置 WCF 服务，然后通过 JSON 合约传递数据。这样，您将拥有一个保存 EF 数据的中央服务，然后根据不同应用程序的需要公开功能。
它是更短期的设置工作（希望您的服务/存储库层是在 IoC 的情况下完成的，以便可以轻松插入），但如果您的 EF 数据发生很大变化，这意味着您可以更新一个中央服务，而无需更新您的每个客户端应用程序。
这里有一个很好的参考线程： https://stackoverflow.com/questions /973017/哪里可以找到好的-wcf-视频-教程
You could setup a WCF service and then pass your data via a JSON contract. That way you'd have a central service that holds your EF data, and then just exposes functions based on what the your different applications need.
Its more short term work to setup (hopefully your service/repository layer was done with IoC in mind to allow it to be easily plugged in) but if your EF data changes a lot, it means you can update the one central service without having to update each of your clients apps.
There's a good reference thread here on S.O: https://stackoverflow.com/questions/973017/where-to-find-good-wcf-video-tutorials