在 BLL 或 UI 中使用 Linq-to-SQL 实体？
前几天，我有一位客户寻求构建一个简单的 WPF LOB 应用程序的建议。他们基本上想要一个数据库的 CRUD 应用程序，主要目的是作为 WPF 培训项目。
我还向他们展示了 Linq To SQL，他们印象深刻。
然后我解释了直接从 BLL 或 UI 代码使用 L2S 实体可能不是一个好主意。他们应该考虑类似存储库模式的东西。
那时我已经感觉到过度设计的警钟在他们的脑海中响起（在某种程度上也在我的脑海中）。他们真的需要一个简单的 CRUD 应用程序那么复杂吗？ （好吧，它可以有效地充当他们的 WPF 培训项目，但让我们假装它变成了一个“真正的”应用程序）。
- 您是否认为在整个应用程序中使用 L2S 实体是可以接受的？
- （根据经验）稍后重构以使用另一个持久性框架有多困难？
在我看来，如果 UI 层使用 L2S 实体作为简单的 POCO（不涉及任何 L2S 特定方法），那么以后如果需要的话，应该很容易重构。
他们确实需要一种集中 L2S 查询的方法，因此需要某种方法来管理它，即使他们确实直接使用 L2S 实体。因此，在某种程度上，我们已经在推动 DAL/DAO/Repository 的某些方面。
我发现 Repo 的主要问题是 L2S 实体和某些域模型之间映射的痛苦。这真的值得吗？你可以在 L2S 实体上“免费”获得很多东西，我认为一旦映射到另一个模型，这些实体就很难使用。
想法？
I had a client ask for advice building a simple WPF LOB application the other day. They basically want a CRUD application for a database, with main purpose being as a WPF training project.
I also showed them Linq To SQL and they were impressed.
I then explained its probably not a good idea to use that L2S entities directly from their BLL or UI code. They should consider something like a Repository pattern instead.
At which point I could already feel the over-engineering alarm bells going off in their heads (and also in mine to some extent). Do they really need all that complexity for a simple CRUD application? (OK, its effectively functioning as a WPF training project for them but lets pretend it turns into a "real" app).
- Do you ever think its acceptable to use L2S entities all through your application?
- How difficult is it (from experience) to refactor to use another persistence framework later?
The way I see it, if the UI layer uses the L2S entities as a simple a POCO (without touching any L2S specific methods) then that should be really easy to refactor later on if need be.
They do need a way to centralize the L2S queries, so some sort of way to manage that is needed, even if they do use L2S entities directly. So in a way we are already pushing toward some aspects of DAL/DAO/Repository.
The main problem with Repo I can see is the pain of mapping between L2S entities and some domain model. And is it really worth it? You get quite a lot "for free" on L2S entities which I think would be hard to use once you map to another model.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
始终使用 L2S 实体的唯一主要缺点是您的 UI 需要了解并绑定到具体实体。这意味着您的 UI 知道您的数据层。通常不是一个好主意。对于任何有可能变得严肃的事情，你确实需要一种分层的方法。
也就是说，完全可以在分层架构中使用 LINQ-to-SQL 实体本身，而无需了解数据层：提取实体的接口并绑定到它们。
请记住，所有 L2S 实体都是部分类。创建反映您的实体的接口（
Refactor => Extract Interface是您的朋友）并创建实现接口的实体的部分类定义。将接口本身（并且仅接口）放在 UI 和业务层引用的单独 .DLL 中。让您的业务层和数据层接受并发出这些接口，而不是它们的具体版本。您甚至可以让接口实现 INotifyPropertyChanging，因为 L2S 实体本身实现这些接口。这一切都很顺利。然后，当/如果您需要不同的持久性框架时，您在 BL 或 UI 中完全没有痛苦，只有在数据层中——这就是您想要的地方。
The only major drawback to using L2S entities all the way through is that your UI needs to know about and bind to the concrete entities. That means your UI knows your data layer. Not usually a good idea. You really want a layered approach for anything that has the potential to be serious.
That said, it's perfectly possible to use the LINQ-to-SQL entities themselves in a layered architecture without knowledge of the data layer: extract interfaces for the entities and bind to them instead.
Keep in mind that all L2S entities are partial classes. Create interfaces that reflect your entities (
Refactor => Extract Interfaceis your friend here) and create partial class definitions of your entities that implement the interfaces. Put the interfaces themselves (and only the interfaces) in a separate .DLL that your UI and Business Layer reference. Have your Business Layer and Data Layer accept and emit these interfaces rather than the concrete versions of them. You can even have the interfaces implementINotifyPropertyChanging, since the L2S entities themselves implement those interfaces. And it all works peachy.Then, when/if you need a different persistence framework, you have no pain at all in the BL or UI, only in the data layer -- which is where you want it.
存储库并不是什么大问题。请参阅此处，了解它们在 ASP.NET MVC 中的使用情况：
http://nerddinnerbook。 s3.amazonaws.com/Part3.htm
Repositories are not a big deal. See here for a pretty good treatment of their use in ASP.NET MVC:
http://nerddinnerbook.s3.amazonaws.com/Part3.htm
基本上我们为一个项目所做的就是我们有一个业务层，它对 L2S 对象执行所有“LINQing”...本质上通过“管理器对象”将所有查询集中到一个层（我猜这些有点类似于存储库） ）。
我们没有使用DTO来映射到L2S；因为我们觉得这个项目不值得付出努力。我们的部分逻辑是，随着越来越多的 ORM 支持 Iqueryable 以及与 L2S 类似的语法（例如实体框架），那么切换到不同的 ORM 可能不会那么糟糕，所以在我看来，这并不是什么坏事。 。
Basically what we did for a project was that we had a Business layer that did all of the "LINQing" to L2S objects... in essence centralizing all querying to one layer via "Manager Objects" (I guess these are somewhat akin to repositories).
We did not use DTOs to map to L2S; as we didn't feel is was worth the effort in this project. Part of our logic was that as more and more ORMs support Iqueryable and similar syntax to L2S (e.g. entity framework), then it probably wouldn't be THAT bad to switch to a different ORM, so its not that bad of a sin, IMO.
这要看情况。如果您开发的产品生命周期较短，那么如果您使用 L2S，则可以轻松、快速地连续完成所有工作。但是，如果您制作的产品寿命较长，并且可能需要长期维护，那么您最好考虑适当的持久层。
如果您在所有层中都使用 L2S，那么您一定不要考虑重构它们以使用另一个持久性框架。这正是在持久层中使用 NHibernate 或实体框架等框架的优点，虽然它需要预先付出一些额外的努力，但从长远来看将很容易维护
That depends. If you do a short lived product you can get things easily wired up in a quick succession if you use L2S. But if you do a long lived product which you might have to maintain for a long duration, then you better think about a proper persistence layer.
If you use L2S in all your layers, well then you must not think about re-factoring them to use another persistence framework. This is exactly the advantage of using a framework like NHibernate or Entity Framework in your persistence layer , that though it requires a bit of extra effort upfront it will be easy to maintain in the long run
听起来您应该考虑 WPF 的 ViewModel 模式
http://msdn。 microsoft.com/en-us/magazine/dd419663.aspx
It sounds like you should be considering the ViewModel Pattern for WPF
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx