我有一个我正在研究的客户/项目，他们的解决方案是大规模的。使用.NET 3.5 / VS2008 / MVC 2 / EF / LINQ-SQL
问题是（我从哪里开始？）一切都被过度抽象出来了。它只是为了创造一个新的实体而引起很多麻烦。创建一个服务存储库，然后是数据存储库，模型，DTO的...列表继续。
我目前面临的一个问题是，如果我需要基于相关实体执行IQueryable，那么LINQ-SQL无法转换该代码。我甚至无法解释为什么它不可能。
无论如何，为了切入追逐 - 我被赋予了找到一个易于整合到解决方案中的微型ORM的任务，并且在没有我们正在经历的所有麻烦的情况下完成工作。
现在，我们还需要它，以便它可以与IQueryable场景一起使用，并轻松地提取相关的对象/实体。
性能是另一回事，目前它很慢，但我明白为什么。 如果我没有多大意义的话，我的思绪目前到处都是如此道歉。
我看到Dapper有良好的声誉。我倾向于它，但我很容易融入....的解决方案。
ASP.NET/Some顶层 基础设施/ LINQ-SQL DTO的 ServiceRepository DataRepository
大约96％的DTO / Repos / Entity /无论接口是什么。
就个人而言，我会沿着使用DataReader和SPROCS /解析结果的路线走下去。但是想要快速，干净（如果可能的话）并减少麻烦。
我强调IQueryable，因为网站上的某些部分需要搜索/过滤LARGE表（历史记录）。使用Telerik网格控件为我们提供了一些灵活性，让我们可以在执行之前构建LINQ-SQL查询。 但是我之前提到的问题之一就是 - LINQ-SQL无法转换存在包含扁平化数据的ViewModel的场景，也许还有包含我们需要的相关实体的DTO。
的Bleh。复杂！困惑。我有时会蜷缩起来哭泣！
感谢您的回复（和安慰！）