我想写一个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();
}
我使用此函数来获取主体模型查询：
public IQueryable<DataAccess.Model.Group> GetQuery()
{
ShamsEntities Entities = new ShamsEntities();
return Entities.Set<DataAccess.Model.Group>();
}
我希望看到所有Names以("A")开头的行，但结果是整个表的行。
如果您将SQL查询从另一层传递到DAL，那么它就不是您的DAL，因为SQL本质上是"DA(数据访问)"，因此应该只存在于DAL中。您可能希望为每种类型的查询创建一个方法，传递一个Filter类型对象，或者可能向DAL传递一个表达式对象，然后DAL可以解析并运行相关的SQL。否则，如果你想换掉你的数据访问方法，例如使用XML文件而不是数据库，你将不得不更改所有的代码，而不仅仅是DAL，这将打破将其分离到不同层的初衷！
p.S.加密可能不应该是DAL的责任。。。
编辑：您链接的文章中的这段解释了我的意思：
在数据访问层中封装数据访问功能。数据访问层应隐藏数据源访问的详细信息。它应该负责管理连接、生成查询，以及将应用实体映射到数据源结构。消费者数据访问层的使用应用程序实体，如自定义对象、TypedDataSets和XML，并且不应该知道数据的内部细节接入层。以这种方式分离关注点有助于应用开发和维护。
编写查询是一个业务逻辑问题，而不是DAL问题。需要哪些实体，它们是如何成形和排序的，这些都是业务逻辑方法或事务脚本的细节。如果您正在编写一些业务逻辑，并且需要跳到DAL来实现一种返回所需数据的新方法，那么您正在混合各种问题。
DAL应该隐藏所使用的存储库的详细信息，因此LINQ的发明使得查询可以以存储库不可知的方式和业务逻辑层的语言来表达。
LINQ还支持查询组合和延迟执行，因此，与启用了LINQ的存储库或DAL(如EF DbContext)交互的预期和推荐方式是，业务逻辑层从IQueryable属性开始，并构建自定义查询。