C# asp.net-mvc-3 dapper n-tier-architecture

使用dapper时sql放在哪里？

发布于 2024-11-07 03:30:43 字数 285 浏览 1 评论 0原文

我在工作中使用 dapper 进行 mvc3 项目，我喜欢它。但是，使用 dapper 时应该如何对应用程序进行分层？目前，我只是将所有 sql 直接填充到控制器中（slap），但我正在考虑使用静态字符串创建一个类。所以我可以这样做

var reports = Dapper.Query<Report>(conn, MySql.ReportsRunningQuery)

How do you store your sql when using dapper?

原文

I'm using dapper for a mvc3 project at work, and I like it. However, how are you supposed to layer the application when using dapper? Currently I just have all my sql stuffed directly in the controller (slap) but I was thinking of making a class with static strings.. So I could do

var reports = Dapper.Query<Report>(conn, MySql.ReportsRunningQuery)

How do you store your sql when using dapper?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

帅气尐潴 2024-11-14 03:30:43

我会说将 sql 放在您本来应该放置等效 LINQ 查询的位置，或者将 sql 放在 DataContext.ExecuteQuery 的位置。至于那在哪里……好吧，这取决于你，取决于你想要的分离程度。

但是，我个人认为将 SQL 隐藏在远离 Query 调用的单独类中没有任何好处 - 您想要在上下文中查看它们，以便可以轻松验证数据（实际上是参数）。您还可能在原位构建查询（仍参数化）。但对于常规静态查询，我会将 TSQL 作为文本保留在代码附近，除非我有充分的理由需要将其抽象化，即

var reports = conn.Query<Report>(@"
select x.blah, y.blah
from x (snip)
where x.ParentId = @parentId and y.Region = @region", new {parentId, region});

（另请注意替代扩展方法上面的用法）

IMO，上面的关键是您任何其他地方极不可能重复使用该查询 - 逻辑将被放入一个方法中，并从多个位置调用该方法。因此，您可能用来将查询隐藏在中央包装器后面的唯一其他原因是您是否需要支持不同的数据库提供程序（使用不同的 SQL 方言）。这比人们想象的要罕见。

I would say put the sql where you would have put the equivalent LINQ query, or the sql for DataContext.ExecuteQuery. As for where that is... well, that is up to you and depends on how much separation you want.

However, personally I see no benefit hiding the SQL in a separate class away from the Query<T> call - you want to see them in context so you can easily verify the data (and indeed, the parameters). You might also be constructing the query (still parameterised) in situ. But for a regular static query I would keep the TSQL as a literal near the code, unless I have good reason to need it abstracted, i.e.

var reports = conn.Query<Report>(@"
select x.blah, y.blah
from x (snip)
where x.ParentId = @parentId and y.Region = @region", new {parentId, region});

(note also the alternative extension method usage in the above)

IMO, the key in the above is that it is extremely unlikely that you would ever re-use that query from any other place - the logic would instead be put into a method, and that method called from multiple places. So the only other reason you might use to hide the query behind a central wrapper is if you need to support different database providers (with different SQL dialects). And that is rarer than people make out.

回复收藏 0 原文

万劫不复 2024-11-14 03:30:43

使用资源文件对我们来说确实很有用。我们在名为 /Sql 的文件夹中创建 .sql 文件，并将它们拖到 SqlResource 对象的“文件”部分中。资源文件的“字符串”部分对于较小的 SQL 片段（例如我们可能正在查询的函数）来说非常干净且容易。

所以，我们的 sql 看起来像：

var reports = conn.Query<Report>(SqlResource.Blahs_get, new {parentId, region});

这使存储库真正干净。将所有 sql 放在资源文件中还有其他好处，因为您可以迭代条目并可能使用 PARSEONLY 查询数据库，以确保如果数据库对象更改，您的查询将会中断（请注意，这主要是但不是） 100% 可靠）。

因此，总而言之，对于我们来说，资源文件使事情真正保持干净，但对于 Marc Gravell 来说，它们并不是为了在生产代码中可重用......每个 sql 语句只能由应用程序中的一个点使用。

Using a resource file is really useful for us. We create .sql files in a folder call /Sql and drag them into the 'Files' section of our SqlResource object. The 'Strings' section of the resource file is really clean and easy for smaller snippets of sql (e.g. functions we may be querying).

So, our sql looks like:

var reports = conn.Query<Report>(SqlResource.Blahs_get, new {parentId, region});

This keeps the repositories real clean. And there are additional benefits to having all of your sql in a resource file in that you can iterate over the entries and potentially query the db with PARSEONLY to make sure that if db objects change your queries would break (note that this is mostly but not 100% reliable).

So, to conclude, for us Resource files keep things real clean, but to Marc Gravell's point they are not for reusability within the production code...each sql statement should only be used by one point in your application.

回复收藏 0 原文

背叛残局 2024-11-14 03:30:43

虽然这个问题现在已经相当老了，但我想进一步建议 SQL 的外部存储。 Visual Studio（至少 2015 年以上）具有语法突出显示功能，以及用于 *.sql 文件的小型调试器和连接管理器。这些文件可以进一步标记为嵌入式资源，并完全包含在程序集中，但与代码分开。您将越来越讨厌看到嵌入在未经语法验证的字符串中的无色 SQL。

我在最近的所有项目中都采用了这种模式，并与 Dapper 这样的 ORM 相结合，C# 和 SQL 之间的接口变得非常少。我在 GitHub 上有一个扩展 Dapper 的开源项目，它可以提供示例以及NuGet 包。它还包括一个受小胡子启发的字符串替换引擎，这对于模板化脚本以使其可重用或插入动态过滤条件非常有用。