我正在开发一个具有非常非规范化数据库的大规模性能关键型asp Web应用程序（出于性能原因，大量数据在表中重复）。该应用程序具有很高的性能和关键性。几乎没有任何形式的n层设计感。我无法触摸数据库，它是刻在石头上的。
现在我需要构建一些其他应用程序来访问c＃（.net 3.5）中的相同数据。在这样做时，我被要求构建一个新的“核心”，以后可以在转移到MVC时使用，所以我想最好引入某种数据 - 访问层来保存实体类和存储库，负责crud操作。
我一直在阅读有关存储库模式和LinqToSql的内容，所以我想我知道它们的基础知识。应该构建的新应用程序当然应该在两周前发布，因此在开始工作之前，我无法花费大量时间来创建庞大的框架或上课。我愿意每天读一本书，但我需要快速入门。
我的问题是，在考虑LinqToSql和存储库模式作为解决方案时，我是否在正确的道路上？为什么不使用您喜欢的代码生成器生成实体并使用断开连接的记录集查询数据库旧样式？使用LinqToSql时，我是否放松了对sql查询的控制？我应该担心性能吗？我完全错了吗？
我希望我能正确解释这个问题。如果有任何未解决的问题，请随时提出。
答案 0 :(得分：1)
有大量的映射工具可以帮助完成这项任务，但实际上就可维护性来说，你可能最好自己动手做（特别是如果这个数据库模型不太可能变化）。
如果我遇到你的情况，我会创建一个通用类来表示你在数据库中存储的内容，然后使用静态方法为你的数据层创建类。每种方法只执行一个应用程序需要的任务（即添加，编辑，获取，搜索等），并使用内置的SQLCommand / SQLDataReader对象来执行此操作，最好是调用存储过程。对于'get'类型方法，它们将返回您的第一组类（或它们的列表）。
这个过程比使用框架/ linqtosql更耗时，但是你找不到比这更好的方法，或者更灵活（因为你实际上是编写代码;它没有生成）。 / p>
答案 1 :(得分：0)
几个星期前我们遇到了完全相同的问题。我们最初是代码生成我们的实体，Dal和基本BLL。但是，如果没有集中式通用解决方案，我们必须编写广泛的代码来加载引用的实体，并且集合将极其复杂。
我们已经使用了一个很棒的本土代码生成器，而且我们几乎所有的业务实体都不是聚合，它们大多数是1-1（数据库表）（大多数情况下）。我们真的想使用LinqToSql，但我们使用属性进行验证，并且使用LinqToSql设计器并没有实现这一点。它也不允许我们通过网络发送查询。
所以我们决定使用我们的代码生成器来生成我们的LinqToSql实体。我们还使用了Interlinq，它允许我们通过网络发送查询。我们有一个存储库工厂，可以处理所有linqToSql查询。基本上这只包含一个LinqToSql datacontext或一个Interlinq datacontext，具体取决于我们是否需要通过线路发送查询。
此解决方案对我们非常有用，并且允许我们直接查询数据并使其保持实时。