我正在与ADO.net实体一起处理这个有趣的事情，需要你的意见。通常会创建一个解决方案来提供服务（WCF或Web服务）以允许通过实体框架访问数据库，但我正在开发一个内部运行且几乎一直具有域访问权限的应用程序。问题是，为应用程序创建数据服务以进行接口是否是一种好的做法，或者我是否可以直接从WPF应用程序转到实体框架。在这种情况下，最佳做法是什么，以及两种不同方法的优点和缺点是什么。
答案 0 :(得分：0)
这实际上取决于复杂程度和所需的耦合/模块化水平。我认为一个很好的折衷方案是在它自己的库中创建一个EF模型，并使用简单的抽象级别。在这种情况下，如果您选择更改模型以使用公开的服务而不是直接访问，那么重构现有代码并不是一件大事，新服务可以利用现有的库。
答案 1 :(得分：0)
通过直接使用实体框架，您是指WPF应用程序是连接到数据库，还是仍然使用服务但重用实体？
如果这是第一种方法，我倾向于反对这一点，因为它意味着连接到数据库的多个客户端，a）是一个额外的安全问题，b）从许可角度来看可能使其更加昂贵，并且c）意味着你没有获得连接池的好处。数据库是最昂贵的扩展项目，因此我尝试设计解决方案以使用服务并减轻数据库的压力。但有时候这是合适的。我注意到的一件事是，直接开始连接的应用程序往往会被重构，以便稍后通过服务;反过来很少发生这种情况。但也可能是YAGNI的一个案例。
如果这是第二种方法，我认为没问题。对于那些看着WCF的人来说，考虑“面向服务”是很常见的 - 也就是说，服务和事物之间应该有一个严格的契约，不应该共享。但是，“多层”应用程序（仅设计为具有一个客户端）也是完全有效的架构，并且不需要如此分离。在这种情况下，重用服务边界两侧的实体应该没问题。但是，我不确定这与EF有什么关系，因为除了实验我没有使用它。