我有即将到来的要求，我不确定EF是否是正确的方法。
基本上我有一个要实现的Web服务契约，它有一些返回特定类的方法（DataContract类具有DataMember'd属性，因此它们可以正确序列化）。构成类的数据将是针对后端数据库的查询结果。
在最低级别，我知道我可以在数据库中编写一些存储过程，这些过程将返回我可以手动连接到自定义类的数据行，并从数据层类中调用存储过程（存储的调用） procs，返回自定义类）。
我想知道我是否可以使用ADO.NET实体框架，但我理解这会从数据库表中创建实体类。我的自定义类与任何数据库表都不相似。存储过程执行聚合和表连接以生成类。
我在这里错过了EF的可能性吗？或者我会更好地使用存储过程/手动连接数据层中的自定义类？
Web服务将托管在SharePoint 2010中，因此我仅限于ASP.NET 3.5。我想我会使用模式和实践来访问数据层，除非有更好的想法。
答案 0 :(得分：3)
鉴于您已表示只能使用.NET 3.5，您将使用{1.}}的EF 1.x. EF 4.x得到了很大改进，但不幸的是需要.NET 4。
DAAB当然是一种替代方案，但您仍需要从数据中映射出您的服务实体（即DAAB不是ORM）
IMO EF在与LINQ一起使用时会自成一体，特别是在与查询一起使用时 - 如果您发现正在编写许多形式为GetXXXByYYY（或使用大量临时或动态sp_executesql）的SPROC来填充您的实体，那么启用LINQ的ORM非常有意义。但是，如果你只有一些具有良好定义接口的重击中的PROC，那么ORM可能会过度。
答案 1 :(得分：2)
如果您的应用程序的对象模型与数据库中的数据模型明显不同，那么我将坚持使用经典的ADO.Net +存储过程来进行聚合和表连接。我的观点是，在这种情况下，任何ORM都会带来更多麻烦而不是利益。