您是否将 Linq2SQL 查询放在各处或放在专用的 DAL 类中？
我总是在各处插入我的 Linq2SQL 查询，几乎在每一个班级中。
我想知道您将 Linq2SQL 查询放在哪里的策略是什么？
您是否将它们放在单独的数据层类中，或者将它们存储在各处使用它们的地方？
我认为我需要更改 Linq2SQL 查询的策略并将它们存储到单独的 DataLayer 类中。 我认为如果我要能够有效地进行 TDD 并遵守依赖注入和 Solid 原则，这是必须的。
I have always inserted my Linq2SQL queries all over the place, in almost every class all over the place.
I woud like to know what your strategy about where to put your Linq2SQL queries?
Do you put them in separate datalayer classes or do you store them where they are used all over the place?
I think that I need to chang my strategy for Linq2SQL queries and store them into separate DataLayer classes. I think that it is a must if I am to be able to do TDD efficiently and to comply with Dependency Injection and the Solid principles..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我将所有 LinqToSQL 调用完全封装到一个 DAL 中。 我的网站和业务层不了解我正在使用的持久性框架。 这样，如果 LinqToSql 真的死掉了，或者如果我决定使用一个全新的框架，我就不必寻找所有我进行数据库调用的地方。
它还有助于可重用性。 我可以在使用相同数据库的其他项目中使用相同的 Business 或 DAL。
I completely wrapped all my LinqToSQL calls into a single DAL. My Website and Business Layers have no knowledge of the persistence framework I'm using. This way, if LinqToSql really does die or if I decide I want to use a whole new framework I don't have to hunt down all the places I made DB calls.
It also helps with reusability. I can use the same Business or DAL in other projects that use the same database.
LINQ 是一种语言构造。 它所需要的只是您的 DAL 将您的实体公开为 IEnumerable 或 IQueryable，并且您可以对其使用 LINQ。 您的 DAL 可以基于 LINQ2SQL 或 LINQ2Entities 或您自己的自定义代码 - 只要它正确公开您的实体即可。 您可以获得一些优势，例如，如果使用 LINQ2SQL，则可以延迟查询执行，但这并不是绝对必要的。 我认为避免在 DAL 之外使用 LINQ 是没有意义的。 如果我想用其他不基于 LINQ2SQL 的东西替换 DAL，我可以。 只要我维护基于 LINQ 的代码所期望的接口就可以了。
编辑：对我来说最重要的是，在到达 DAL 之前，它们不是 LINQ2SQL 查询，它们只是 LINQ。 LINQ 不会从语言中消失，除非它被更好的东西取代。 之所以成为 LINQ2SQL，是因为 DAL 是使用 LINQ2SQL 实现的。 我的其余代码不知道（或关心）事实如此。 它可以是 LINQ2Objects 或 LINQ2Entities 或...
LINQ is a language construct. All it requires is that your DAL expose your entities as IEnumerable or IQueryable and you can use LINQ against it. Your DAL could be based on LINQ2SQL or LINQ2Entities or your own custom code -- as long as it exposes your entities properly. You get some advantages, like delayed query execution if you use LINQ2SQL, but it's not strictly necessary. I see no point in avoiding the use of LINQ outside of the DAL. If I want to replace the DAL with something else not LINQ2SQL-based, I can. As long as I maintain the interfaces that the LINQ-based code expects I'm ok.
EDIT: The bottom line for me is that until they hit the DAL, they aren't LINQ2SQL queries, they're just LINQ. LINQ isn't going to disappear out of the language unless it's replaced with something better. The thing that makes it LINQ2SQL is that the DAL is implemented with LINQ2SQL. The rest of my code doesn't know (or care) that this is so. It could be LINQ2Objects or LINQ2Entities or ...
将所有 Linq2SQL 查询放入一个单独的类中，可以在测试访问它的业务对象时轻松将其替换为“模拟/存根”。
还是我错了？
Putting all my Linq2SQL queries into a separate class makes it easy to replace it with a "mock/stub" when testing the business objects that access it.
Or am I wrong?
如果您将 LINQ 查询视为 LINQ2SQL 查询，那么您就有点没有抓住要点。
您有 LINQ 查询。 您的业务层通过在数据层（数据上下文）上进行 LINQ 查询来访问数据层。 LINQ2SQL 是允许 LINQ 查询访问 SQL Server 的组件。
这是一个严重的过度简化，但一般的观点是，如果您将所有 LINQ 隐藏在业务层之外，您就不会真正从其存在的理由中受益。
如果 LINQ2SQL 不允许您将数据库架构抽象到您喜欢的程度，那么您应该考虑使用实体框架。
If you are thinking of your LINQ queries as being LINQ2SQL queries you slightly missing the point.
You have LINQ queries. Your business layer accesses the data layer by making LINQ queries on the data layer (a datacontext). LINQ2SQL is the component which allows LINQ queries to access SQL Server.
Thats a serious oversimplification but the general point is if you hide all your LINQ away from the business layer your not really benefiting from its reason to exist.
If LINQ2SQL doesn't allow you to abstract your DB schema to the degree that you like then you should consider using the Entity Framework instead.
当我需要访问数据库时，我使用连接字符串（哪个数据库）和一个映射文件（要映射哪些表）来实例化 Helpers.DataContext。
这可以很好地分离关注点。
When I need access to the database I instantiate the Helpers.DataContext, with a connection string (which database) and a mapping file (which tables to map).
This keeps a nice seperation of concerns.
我亲自创建“基本”查询并公开 IQueryable。
在我的业务对象中，我喜欢返回具体结果，因此我通常将 QueryByExpression 样式方法设为内部方法，然后创建方法存根，在其中可以传入我的条件，并在处理查询的方法中，从数据库，并返回结果的 IEnumerable，而不暴露应用程序的其余部分以需要上下文或任何内容。
但是，就像上面许多人所说的那样，我不得不同意——将 IQueryable 暴露给代码并不可怕，它只是让你与 Linq2Sql 的东西更加紧密地联系在一起。
如果您不介意创建公开方法的业务对象，但不公开 IQueryable 类型，我觉得这样更好，但设置和配置业务对象会更乏味。 我觉得它也更容易测试，但这只是我。 还要考虑可重用性，如果你修复了一个 bug，那么 2 年后它就不再存在于代码中的 30 个不同位置。
只是我的2分钱。
I personally create the "base" query in and expose the IQueryable.
In my business objects, I like to return concrete results, so I usually make the QueryByExpression style method internal only, and then create method stubs where I can pass in my criteria, and in the method I process the query, get the results from the database, and return an IEnumerable of the results, not exposing the rest of the app to need the context, or anything.
But, like many of the people said above, I would have to agree -- exposing your IQueryable to your code isn't horrible, it just makes it so you are a little more tied to your Linq2Sql stuff.
If you don't mind creating business objects that expose methods, but does not expose the IQueryable type, I feel that's better, but its more tedious to setup and configure your Business Object. Its also easier to test I feel, but that's just me. Make for re-usability also, and if you fix a bug, it doesn't exist in 30 different spots in your code 2 years later.
Just my 2cents.
我不一定会创建单独的业务对象，因为这就是 LINQ2SQL 的要点，并且您将重新创建许多使 LINQ2SQL 如此出色的东西。
不过，我建议创建一个包含静态类的类库，其中包含 L2SQL 代码。 这为您提供了能够替换单个程序集来更改业务逻辑的优势。 此外，如果您有额外的方法来访问数据，那么您的静态类是该逻辑的好地方。
不过，如果您的需求稍微复杂一点并且您不介意创建自己的映射，我会同意 Florian 的观点。
I wouldn't necessarily create separate business objects simply because that is the point of LINQ2SQL and you would be re-creating a lot of what makes LINQ2SQL so great.
I would however recommend creating a class library with static classes with your L2SQL code in it. This gives you the advantage of being able to replace single assemblies to change your business logic. Additionally if you have extra methods for accessing data, your static classes are a good place for that logic.
I would however agree with Florian if your needs are a bit more complex and you don't mind creating your own mappings.
我的最新项目使用 ASP.NET MVC 框架和 LINQ-to-SQL。 因此，我的数据层严重依赖存储库模式。 由于这是我的第一个 LINQ-to-SQL 项目，因此数据库架构在单个 DataContext 类中表示。 随着后续项目的出现，我可以拆分通用的 DataContext 以便重用。
我创建了一个接口，其中包含我计划为特定存储库实现的所有签名，该存储库通常代表单个复杂对象。 基于该接口，我实现了两个类：一个用于生产，一个用于测试。 我的所有 LINQ-to-SQL 查询都保存在存储库类中。 在我的控制器代码中，我访问数据访问方法的存储库。 我的观点中不包含疑问； 我使用自定义视图模型类，这些类使用存储库方法填充在控制器中。
My latest project uses the ASP.NET MVC framework and LINQ-to-SQL. For that reason, I depend heavily on the Repository pattern for my data layer. Since this is my first LINQ-to-SQL project, the database schema is represented within a single DataContext class. As later projects come along, I can splinter out common DataContexts for reuse.
I create an interface that holds all the signatures I plan to implement for a particular repository, which typically represents a single complex object. Based on that interface, I implement two classes: one for production, one for testing. All my LINQ-to-SQL queries are held in repository classes. In my controller code, I access the repositories for my data access methods. I do not include queries in my views; I use custom view model classes which get populated in the controllers using repository methods.
我在 DAL DLL 中使用了 Linq2SQL。 我喜欢关注点分离，加上任何其他站点或应用程序需要访问同一数据库，您可以重用 DLL 中的大量代码。 因此，所有 Linq2SQL 都存储在这个 DAL 中。 现在，对于 Linq 本身，我根据需要在服务层和表示层中使用它。
Linq2SQL DLL 布局
创建映射 .dbml 文件以将 SQL table.columns 映射到 Linq Catalog (SqlRepository)
编写与服务层类匹配的 sql 存储库类并使用正确的 Linq Catalog 类。
为每个 sql 存储库类添加了接口，以便服务层直接与接口一起工作
。编写了 sql 存储库类与服务层来回传递的业务模型。
I've used Linq2SQL in a DAL DLL. I like the seperation of concerns plus any other sites or apps need to access the same database you can reuse quite of bit of code from your DLL. So all the Linq2SQL is stored away in this DAL. Now for Linq itself I use that in both my service and presentation layer depending on the need.
Linq2SQL DLL layout
Creating the mapping .dbml file to map SQL table.columns to a Linq Catalog (SqlRepository)
Wrote sql repository classes that match up to a Service layer class and use the proper Linq Catalog class.
Added interfaces for each sql repository class so the service layer works directly with the interface
Wrote business models that the sql repository classes pass back and forth with the service layer.