我正在设计一个相当大的Silverlight项目。我打算大量使用模块化，所以我选择了 MEF 和 PRISM 来帮助我。但是，在数据方面，我不太清楚如何解决以下问题：
让我们说我不想为鞋店和 petshop 制作软件。他们需要的数据中有90％是相同的，但鞋店的产品表需要不同于宠物商店的列。
所以我们需要对这部分进行模块化。我不能只为此制作两张桌子，因为我希望以后可以写一个模块，比如说书店。
在EF方面，我们需要一组类，例如属于shoeshop-module的 Shoe ， ShoeType 和公开这些类的 DomainService 。在客户端（SL）方面，我们需要一组表示该数据的Views和ViewModel，以及一个 IProductService 接口的实现，它提供对其他模块的上下文的访问。
我的问题是：
答案 0 :(得分：2)
当你说你想要一家鞋店和一家宠物店时，我认为它可以扩展到超过两种类型？
如果它只是两种或三种不同的类型，我会为每个模块提供不同服务的路径。然后显式处理不同的数据集。
如果您可以拥有多种不同的商店类型，您可能需要阅读所谓的“元模型”。这是您在数据库中实际建模另一个模型类型的位置。这样您可以拥有各种不同的产品，但在您的数据库中，您表示它们具有基于产品的不同属性。
举一个具体的例子，想象一下内容管理系统。通常人们可以为不同的页面类型定义不同的字段。例如，“博客帖子”有标题，正文，作者和“通用页面”，只有正文和作者。您可以为每个页面类型创建一个表，也可以尝试在数据库中描述一个页面，这样当人们想要引入新类型时，他们可以在不更新数据库模式的情况下这样做。
好处的流程是你的更通用的模型不关心ShoeShop或PetShop，它只知道它得到一个Shop然后它根据Shop对象上描述的内容计算出属性。一旦发生这种情况，在您的场景中，您只需要一个支持Shop的DataService和一个DbContext。
想象一下像Shop这样的模型，有一个Fields集合，每个字段都有'Value'，'Type'等属性。它可能有点弯曲，它可以非常抽象地处理，所以你会想要制作一个原型，看看你是否觉得舒服 - 如果你最终只选择几种商店类型，那么挑战可能会大大超过好处。
需要注意的另一个问题是，构建一个足以描述所有内容的元模型是一项挑战。它也可以让一些ORM变得更好，因为它们需要复杂的eager加载功能，以确保你不会在元模型中获得可怕的性能加载（我知道因为我们构建了ORM for .NET developers called LightSpeed并且是第一件事之一我们做的是用它表达一个元模型，并调整急切的加载功能，以确保我们做了很好的查询。
我有一个快速的Google，但没有找到任何关于开发元模型驱动的应用程序的指南。
这完善了我的回答 - 你会想要做更多的阅读，而其他人可能会有更好的想法，但所有这些都将在灵活性和复杂性之间取得平衡。
我希望有所帮助。