您是否考虑过使Documents实体抽象?
从 DB 端,您将拥有Documents表,其中仅包含所有 Invoices/Quoations/etc 共享的字段。该字段将有一个 IDENTITY PK - 例如 DocId。
在其他表中,可以存储特定于该文档的附加元数据,并且 PK 是(非 IDENTITY)字段 DocId,它也是Documents表的 FK。
在 EF 端,Documents成为一个抽象实体,其他实体继承自该实体。这允许存在一个很好的 OO 范例,并使您的代码更加健壮。
我们目前正在使用这种方案(EF4/SQL Server)。
您的场景听起来与我们的非常相似 - 考虑使用抽象类。
编辑
以为我会为我实际实现此场景的方式添加更多信息,以使您走上正确的轨道。
由于对您的 Q 状态的评论,我们对您的领域知之甚少,因此很难做出明智的意见。就个人而言,我选择让我的实体抽象,因为某些功能需要一个“混合包”的项目才能一次返回。当然还有其他方法可以做到这一点(例如存储过程),但这允许在我的 UI(顺便说一下是 MVC)和我的服务层之间建立一个很好的流畅接口。
像这样工作-这是我获得单个帖子的方式:
// var is strongly-typed to a "Post"
var somePost = repository.FindSingle(10);
以下是我如何获得混杂的帖子:
// var is strongly-typed to a "ICollection<Post>".
// "Title" is a property on my "Post" abstract POCO
var mixedBagOfPosts = repository.FindAll<Post>(p => p.Title = "Some Title");
这是我获得“评论”(帖子的子项)集合的方式:
// var is strongly-typed to a "ICollection<Review>"
// "Rating" is a property on my "Review" POCO (derived from Post)
var reviews = repository.FindAll<Review>(r => r.Rating == 5.00);
踢球者是我的存储库是用泛型实现的,类型参数确保类型安全:
ICollection<T> FindAll<T>(Expression<Func<T,bool>> predicate) where T : Post
它是这样实现的:
return myContext.Posts.OfType<T>.Where(predicate).ToList();
OfType导致与 T(即子表)的内部连接,因此仅返回那些记录。
当然,我的 UI 和存储库之间也有一个服务层,但这应该能让你走上正轨。
此外,您不必使用整个表达式谓词,我喜欢这个,因为它最大限度地减少了我的界面上的方法数量,并为我的控制器提供了完整的查询能力,同时确保查询被推迟到服务层,但不是更进一步。
如果您不喜欢这样,您当然可以使用常规参数(字符串标题等)。
正如我所说,这个架构适合我的领域需求,所以它可能不一定适合你,但希望它能给你一些见解。