C# 创建SQL查询并将其注入DAL

我想在我的应用程序的底层编写一个DAL来对输入模型、数据规范化和一些其他加密任务进行映射，并且我想限制我的SQL查询只通过DAL运行。 我将dbContext更改为private以实现最后一个。 但为了将查询传递给DAL，我需要一种构建和传递所有类型SQL查询的方法，我可以将它们注入DAL，然后对主要EntityModels运行最终查询

例如，我尝试了这种方法，但没有任何结果：

Main.cs：

IEnumerable<DataAccess.Model.Group> Output = new List<DataAccess.Model.Group>();
Output = from A in Output.Where(P => P.Name.StartsWith("A")) select A;
Group.FakeSelect(Output);

在我的DAL中，我尝试了类似的方法：

public List<Group> FakeSelect(IEnumerable<Group> Query, out List<NewGroup> NewModel)
{
    IQueryable<Group> Source = GetQuery();
    Query = Query.Union(Source);
    return (from A in Query select new NewGroup{....}).ToList();
}

Im使用此函数获取主entityModel查询：

public IQueryable<DataAccess.Model.Group> GetQuery()
{
        ShamsEntities Entities = new ShamsEntities();
        return Entities.Set<DataAccess.Model.Group>();
}

---

我希望看到所有的行的名称都是起始的，但结果是整个表的行。

如果您将SQL查询从另一层传递到DAL，那么它就不是DAL，因为SQL本身就是DA数据访问，因此应该只存在于DAL中。您可能希望为每种类型的查询创建一个方法，传递一个Filter类型的对象，或者向DAL传递一个expression对象，然后DAL可以解析并运行相关的SQL。否则，如果您想交换数据访问方法，例如使用XML文件而不是数据库，那么您将不得不更改所有代码，而不仅仅是DAL，这一点从一开始就无法将其划分为不同的层

另外，加密可能不是DAL的责任

编辑：你链接的文章中的这一段解释了我的意思：

在数据访问层中封装数据访问功能。 数据访问层应该隐藏数据源访问的详细信息。 它应该负责管理连接、生成查询、， 以及将应用程序实体映射到数据源结构。消费者 数据访问层的成员通过抽象接口使用 应用程序实体，如自定义对象、类型数据集和XML， 而且不应该知道数据的内部细节 访问层。以这种方式分离关注点有助于应用 开发和维护

---

编写查询是一个业务逻辑问题，而不是DAL问题。需要哪些实体、它们的形状和排序方式是业务逻辑方法或事务脚本的细节。如果你正在编写一点业务逻辑，需要跳转到你的DAL来实现一种新的方法来返回你需要的数据，那么你就要混合关注了。 DAL应该隐藏所使用的存储库的细节，因此LINQ被发明出来，这样查询就可以用存储库无关的方式和业务逻辑层的语言来表示

---

LINQ还支持查询组合和延迟执行，因此，与启用LINQ的存储库或DAL（如EF DbContext）交互的预期和推荐方式是，业务逻辑层从IQueryable属性开始，并构建自定义查询

您正在滥用DAL，它应该执行查询，而不是BLL，您正在调用一个非静态的，没有实例，也没有所需的out参数，该参数甚至不会编译，并且您正在忽略该方法返回的任何内容，这使得您很难理解从何处获得结果。请尝试重新表述您的问题，以便更清楚地了解您想要实现的目标，并检查您发布的代码-它至少应该可以编译；是您希望top发送给FakeQuery的查询：不是。输出只是一个IEnumerable，当然不是一个查询，也不是一个表达式。我读过一些n层实现，我看到我试图在DAL中强制一些类似持久层的东西。我现在正在使用表达式，但我需要提供所有SQL命令类型，例如GROUPBY、Having、IN、JOIN等。。。。在Stackoverflow中给出了一些答案之后，我很满意我必须将此任务留给上层，并且在这一层中必须有一些其他问题。我在实现之前阅读了下面的文章，我认为在业务层使用映射模型和一些其他任务会很好。那么，我应该在我的DAL里放什么呢？thanksDAL应包含数据访问代码。。。与中一样，在本例中，与持久存储交互的代码是数据库。因此，任何与数据库相关的内容都在这里，而其他内容都不在这里。这意味着，如果您决定将来不再使用数据库，那么该层是唯一需要更改的代码，其他所有代码都将以完全相同的方式继续工作。我建议了3种不同的方法让DAL知道您希望它运行哪些查询，当然还有更多的方法，但不要将SQL从另一层传递到这一层，因为SQL只属于这一层。添加了您链接的文章中的引用，引用了我的意思，似乎同意DAL中应该包含什么？只有EF模型，其他什么都没有？实体模型不是真实的

---

DAL的y部分。EF DbContext是。有时，使用定义存储库的接口，并将EF DbContext作为一个实现是很有用的。您经常会向DbContext添加自定义方法，特别是在遵循CQRS模式时，这使得数据变异成为DAL关注点，而将查询作为业务逻辑关注点。。。因此，在这种方法中，实体模型仍然在DAL中，以便访问DbContext，但您要说的是，它实际上不是DAL的一部分？您是否知道一个开源或示例解决方案可以很好地演示这种方法？首先来自现有数据库的OOB EF代码演示了这一点。实体是基于数据库表创建的，并使用属性或FluentAPI映射回它们。但除了映射属性之外，实体不依赖于DbContext。