业务逻辑对象是否应该了解其 LINQ-to-SQL 数据对象？
我看过几个类似的问题，但没有看到任何直接适用于我的问题，所以如果这是重复的，请原谅我。
为了分离关注点，我尝试以某种方式将我的业务对象与逻辑映射到 .dbml 文件中的 LINQ to SQL 数据对象（顺便说一句，这对我来说相当新）。 但看起来我的业务对象需要了解相应的 LINQ2SQL 对象。 我读了 这篇文章关于尝试使用 xml 映射文件来使用 POCO，这似乎与我想要的类似，只是我没有从表到类的一对一映射由于多对多关系，我需要为其创建一个额外的表。
我可以很好地将数据访问封装在我的业务逻辑中，这样使用我的业务对象的代码不需要了解有关数据库的任何信息，这很好，但业务层仍然与数据访问层紧密耦合，这样如果不更改业务层对象或为不同的数据提供者创建新的对象（实现相同的接口），我就无法更换 DAL。
如何解耦这些层？
I've looked at several similar questions but I didn't see any that directly applied to me, so forgive me if this is a duplicate.
For separation of concerns I'm trying to somehow map my business objects with logic to the LINQ to SQL data objects in the .dbml file (fairly new to this btw). What its looking like though is that my business objects are going to need to know about the corresponding LINQ2SQL objects. I read this article about trying to use POCOs with by using an xml mapping file, and it seems like that's similar to what I want, except that I don't have a one-to-one mapping from tables to classes because of a many-to-many relationship that I needed to create an extra table for.
I can encapsulate the data access in my business logic pretty well such that code that uses my business objects don't need to know anything about the database which is good, but it the business layer is still tightly coupled with the data access layer such that I couldn't swap out the DAL without either changing my business layer objects or creating new ones (that implement the same interfaces) for different data providers.
How can I decouple these layers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定您是否以某种方式与 LINQ to SQL 绑定在一起，但您想要完成的任务几乎是 NHibernate 中的默认任务。 我建议看一下 NHibernate，看看它是否比对抗 LINQ to SQL 更容易。
我发现与工具对抗几乎总是一个坏主意。
Not sure if you are tied to LINQ to SQL somehow, but what you are trying to accomplish is pretty much the default in NHibernate. I recommend taking a look at NHibernate to see if it would be easier to switch than to fight LINQ to SQL.
I've found that fighting a tool is almost always a bad idea.