如何模块化WCF服务+ EF4.1

Question

我正在设计一个相当大的Silverlight项目。我打算大量使用模块化，所以我选择了MEF和PRISM来帮助我。然而，当涉及到数据，我不太清楚如何解决以下问题：

可以说，我wan't借此让该软件为鞋店卖鞋和宠物店。他们需要的数据有90％是相同的，但鞋店需要与petshop不同的产品列。

所以我们需要模块化这部分。我不能只为此写两张桌子，因为我希望能够为后来的书店写一个模块。

在EF方面，我们需要一组类，例如， 鞋,鞋类属于鞋店模块和域服务公开这些类。在客户端（SL）方面，我们需要一组代表该数据的视图和视图模型，并可能实现接口的一个实现，该接口为其他模块提供对上下文的访问。

我的问题是：

1. 你会如何设计不同DomainServices？每个模块一项服务？你是否提供对其他模块的这些服务的写访问权限？
2. 如何管理不同的数据集？你只是为每个数据集制作一个DbContext（比如对于两个实体类型鞋和鞋类）？

Answer 1

我在选择，当你说你想要一个鞋店和一个宠物店你建议它可以扩展超过两种类型？

如果它明确地只是两种或三种不同的类型，我会去每个模块的不同服务的路由。然后明确处理不同的数据集。

如果您可以有n个不同的商店类型，您可能需要阅读所谓的'元模型'。这是您实际为数据库中的另一个模型类型建模的位置。通过这种方式，您可以拥有各种不同的产品，但是在数据库中，您可以表示它们具有基于产品的不同属性。

举一个具体的例子，设想一个内容管理系统。通常人们可以为不同的页面类型定义不同的字段。例如，一个'博客文章'有一个标题，正文，作者和一个'通用页面'，只有正文和作者。您可以为每个页面类型创建一个表格，也可以尝试在数据库中描述一个页面，这样当人们想要引入新类型时，他们可以在不更新数据库模式的情况下进行操作。

关于福利的一个流程是，您的更广义的模型不关心ShoeShop或PetShop，它只是知道它获得一个商店，然后根据Shop对象上描述的内容计算出属性。一旦发生这种情况，在您的场景中，您只需要一个支持Shop的DataService和一个DbContext。

想象一下像Shop这样的模型，有一个Fields集合，每个领域都有像'Value'，'Type'等属性。它可以是一个思维弯曲者，它可以是非常抽象的处理，所以你将会想出一个原型来看看你是否舒适 - 如果你最终选择了几种类型的商店，那么这些挑战可能会轻而易举地超过收益。

另一个需要注意的问题是，构建一个足以描述所有事物的元模型是一个挑战。它也可以让某些ORM变得更好，因为它们需要复杂的热切加载功能，以确保在元模型中不会出现可怕的性能加载（我知道是因为我们构建了一个ORM for .NET developers called LightSpeed，我们做的第一件事情之一是快速带有它的元模型，并调整热切的加载功能，以确保我们确实做出了出色的查询）。

我已经有一个快速的谷歌，但还没有发现任何真正容易遵循开发元模型驱动的应用程序的指南。

这就是我的回应 - 你会想做更多的阅读，其他人可能有更好的主意，但总的来说，它会降低灵活性和复杂性之间的折衷。

我希望有帮助。