使用 Microsoft Entity Framework / Linq to SQL 的独立模块化类
我多年来一直使用 .NET 2 进行 Web 编程（由于我们对所使用的服务器上的其他任何内容的支持有限），但最近开始考虑使用 .NET 4 进行一些新项目。
作为其中的一部分，我一直在尝试学习如何使用 Microsoft Entity Framework / Linq to SQL。看起来它使基础知识变得非常简单，您可以立即构建一个功能齐全的类。然而，现在我开始进一步推动它，我发现了一些我不确定如何解决的问题。
困扰我的事情之一是我不明白如何组织事情。显然，我习惯于将相关类保留在命名空间中，通常这些命名空间反映数据库的布局（例如，命名空间映射到表名前缀）。不过，使用 EF 时，似乎我的每个类都必须位于同一命名空间中。当然，我可以在单独的命名空间中拥有多个数据上下文，但是这样我就失去了 EF 提供的优势，因为这些类之间不再有任何关系。我可以忍受这个，但我觉得我一定错过了什么？
我遇到的另一个更困扰我的问题是，我习惯于构建独立的模块化类，但我不明白 EF 如何做到这一点。例如，我不知道如何编写一个简单的 Save 函数，因为如果您调用 db.SaveChanges() 那么对整个数据库的更改都会被保存 - 如果您调用 mySingleObject.Save() 那么这不会'这似乎是一件理想的事情，因为它还会保存对您碰巧使用过的任何其他对象的更改。鉴于我正在将这个功能构建到类库中，必须从类库外部调用 db.SaveChanges() 似乎也很疯狂，因为我的类库之外的任何内容都不需要了解我的数据如何存储。
我是否忽略了这一点，或者我是否需要改变我的思维方式？
目前，由于这些问题，我正在努力推进我的项目，并且我正在考虑回到普通的旧 SQL。这将是一种耻辱，因为 EF 显然具有一些巨大的优势，而我想充分利用它！
I've been using .NET 2 for web programming for several years (due to the limited support we have for anything else on the servers we're using), but have recently started looking at using .NET 4 for some new projects.
As part of this, I've been trying to learn how to use the Microsoft Entity Framework / Linq to SQL. It seems that it makes the basics very straightforward and you can put together a fully functioning class in no time at all. However, now I'm starting to push it a bit further I'm finding issues that I'm not sure how to get around.
One of the things that's bothering me is that I don't understand how to organise things. Obviously I'm used to keeping related classes in namespaces and generally these namespaces reflect the layout of the database (eg. namespaces map to table name prefixes). Using the EF though, it seems that every one of my classes has to be in the same namespace. I can of course have several data contexts in seperate namespaces, but then I lose the advantages that the EF offers as the classes no longer have any relationship to one another. I can live with this, but I feel like I must be missing something?
The other issue I've got which is bothering me even more is that I'm used to building self-contained modular classes and I don't understand how this is possible with EF. For example, I can't figure out how to write a simple Save function, because if you call db.SaveChanges() then changes to the entire database are saved - and if you're calling mySingleObject.Save() then this doesn't seem like a desirable thing to do as it'd also save changes to any other objects you happen to have been messing around with. Given that I'm building this functionality in to a class library, having to call db.SaveChanges() from outside the class library also seems crazy, because anything outside my class library shouldn't require any knowledge of how my data is stored.
Am I missing the point of this or do I need to change my way of thinking?
At the moment I'm struggling to advance my project because of these issues, and I'm considering going back to plain old SQL. This would be a shame because the EF clearly has some massive advantages, and I'd like to make the most of it!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从未遇到过必须将所有数据库实体保留在同一名称空间中的问题。我认为创建与数据库无论如何相关的命名空间并不明显。我认为这引入了最好一起避免的紧密耦合，特别是您的应用程序不应该关心底层数据存储的架构。我认为命名空间通常用于对逻辑实体进行分组（和范围） - 即与日志记录相关的所有类，或者在本例中，与与持久性存储交互相关的所有类。
在我看来，你的其他担忧同样毫无根据。您能否提供一个示例，说明何时要将某些对象状态提交到存储而不是其他对象状态？ EF 提供了一种执行事务的机制，因此您在这方面做得很好。
一般来说，代表数据库中一行的单个类的活动记录模式正在失效青睐和存储库模式（上一个问题，msdn) 正在取代它。
I've never run into an issue with having to keep all of my database entities in the same namespace. I don't think it's obvious that one would create namespaces that are related in anyway to the database. I think that introduces a tight coupling that's best avoided all together, specifically your application shouldn't care about the schema of the underlying datastore. I think namespaces are commonly used to group (and scope) logical entities - i.e. all classes relating to logging, or, in this case, all classes related to interacting with a persistence store.
Your other concern seems equally unfounded to me. Can you provide an example of when you'd want to commit some object state to the store and not others? EF provides a mechanism for executing transactions, so you are fine on that front.
In general, the active record pattern of a single class representing a row in the database is falling out of favor and the repository pattern (previous question, msdn) is taking it's place.