我正在计划一个应用程序，将有一个基于web的组件和桌面客户端组件。基本上，我计划使用ASP.NET MVC3创建基于web的组件。Entity Framework是一个普通的数据驱动网站，但是我也计划创建一个桌面客户端来扩展网站的功能，这对我来说是一个新的领域，我有点困惑。我知道创建需要访问中央数据库的应用程序的最佳方法是使用WCF，但是我以前没有使用过WCF，但听说它很容易与Entity Framework集成。
所以我知道我想做的当然是可能的，我只是在寻找一些指导如何这个应用程序的独立组件应该粘合在一起，等我应该与WCF和Entity Framework工作第一?或者我应该在使用WCF之前完成基于web的组件?
谢谢,亚历克斯。
有很多方法可以做到这一点，所有这些方法都有不同程度的复杂性。例如，你可以使用实体框架构建你的web应用程序，在同一个web应用程序中，你公开了一个OData服务(WCF数据服务)，它提供了一个RESTful服务，你的WPF应用程序可以使用它来访问数据库。这相当容易，因为WCF数据服务与实体框架配合得非常好。这基本上是一个两分钟的工作(如果你没有做任何花哨的事情)。然后，您的WPF应用程序对数据库的访问基本上与您的web应用程序相同。在它的默认配置中，WCF数据服务只是公开一个EF ObjectContext，并允许对其进行相同类型的操作。我建议您试用一下，看看它是否符合您的要求。
但是，这种方法基本上是允许桌面应用程序访问数据库的快捷方式。在大多数情况下，这是完全没问题的。如果您确实想投入一些精力，您可以对使用实体框架数据源或OData数据源的服务层进行建模。从现在开始，一切都是关于设计模式的。这是有代价的;层的分离是一件很难做到的事情，如果你想做对的话。考虑到。net世界在某种程度上改变了"完成工作"，把这些部分放在一起，很快就能得到一个运行的应用程序是很好的。
你还应该考虑到WPF中的MVVM和web应用程序中的MVC有根本的区别;如果MVC应用程序只是从数据库中提取一个"快照"，那么WPF应用程序可能需要更多的努力和异步编程来感觉自然。
我可以为你提供一些具体任务的指导，比如如何解耦WCF数据服务和实体框架，但从我的经验来看，"做对"的开销是巨大的。如果你不需要服务层，你会有一个愉快的EF和OData的工作经验。
最好先将web组件与wcf集成，您可以使用实体框架，但如果您有一个数据繁重的DB，我建议使用T-Sql本身，它为您提供了很多性能选择。我建议您使用MVP模式构建应用程序模型，因为它可以轻松地从桌面应用程序切换到web应用程序，并且还符合您扩展它的要求。