dgrl格式读取_为性能关键的高容量应用程序构建DAL(Building a DAL for a performance critical, high volume application)...

为性能关键的高容量应用程序构建DAL(Building a DAL for a performance critical, high volume application)

我正在研究一个大规模性能关键的asp Web应用程序，其中有一个非常规非规范化的数据库(由于性能原因，大量数据在表中出现重复)。 该应用程序具有很高的性能，而且性能很高。 几乎没有任何一种n层设计的感觉。 我无法触摸数据库，它被刻在石头上。

现在我需要构建一些访问c＃(.net 3.5)中相同数据的其他应用程序。 在这样做的时候，我被要求构建一个新的“核心”，以后可以在转移到MVC时使用它，所以我猜想引入某种数据访问层是个好主意，这些数据访问层包含实体类和一个库，负责crud行动。

我一直在阅读存储库模式和LinqToSql，所以我想我知道非常基础。 新课程当然应该在2周前完成，所以在我开始工作之前，我无法花费大量时间来创建一个庞大的框架或上课。 我愿意每天阅读一本书，但我需要尽快开始。

我的问题是，当我考虑LinqToSql和存储库模式作为解决方案时，我是否正确？ 为什么不使用您最喜欢的代码生成器生成实体，并使用断开连接的记录集查询数据库旧式样？ 使用LinqToSql时，我是否会失去对sql查询的控制？ 我应该担心表现吗？ 我完全错误吗？

我希望我能正确解释这个问题。 如果有任何疑问，请随时提问。

I'm working on a large scale performance critical asp web application with a pretty much denormalized database (lots of data is duplicated across tables for performance reasons). The application is highly performance critical and large. There is almost no sense of any kind of n-tiered design. I can't touch the database, it's carved in stone.

Now I need to build some additional applications accessing the very same data in c# (.net 3.5). While doing so, I'm asked to build a new "core" which later can be used when moving on to MVC, so I guess it would be a good idea to introduce some kind of data-acess-layer holding the entity classes and a repository, which is responsible for the crud actions.

I've been reading about the repository pattern and LinqToSql so I guess I know the very basics. The new applications that should be build are of course due 2 weeks ago, so I can't really take tons of time to create a huge framework or attend classes before I get to work. I'm willing to read a book a day but I need to get started quickly.

My question is, am I on the right path when thinking about LinqToSql and the repository pattern as a solution? Why not generate the entities using your favorite code generator and query the database old style using disconnected recordsets? Do I loose control over the sql queries when using LinqToSql? Should I worry about performance? Am I completely on the wrong way?

I hope I explained the issue at hand properly. If there are any open questions, feel free to ask.

原文：https://stackoverflow.com/questions/302196

更新时间：2019-11-23 23:27

最满意答案

目前有大量的地图绘制工具可以帮助完成这项任务，但实际上就可维护性而言，您最好自己做(尤其是如果这种数据库模型不太可能改变)。

如果我处于您的情况，我会创建一些通用类来代表您在数据库中存储的内容，然后使用静态方法为您的数据层创建类。 每种方法只需完成一项应用程序需要的任务(即添加，编辑，获取，搜索等)，并使用内置的SQLCommand / SQLDataReader对象来执行此操作，最好调用存储过程。 对于'get'类型的方法，他们会返回你的第一组类(或者它们的列表)。

这个过程比使用framework / linqtosql要花费更多的时间，但是你不会找到另一种比这更好的方法，或者更灵活(因为你实际上在编写代码;它不会生成)。

There are tons of mapping tools out there that are intended to help with this task, but in practicality as far as maintainability goes, you're probably better off just doing it yourself (especially if it is unlikely that this database model will change).

If I were in your situation, I'd create general classes that represent what you're storing in your database, and then create classes with static methods for your data layer. Each method simply does one task that your application needs (i.e. add, edit, get, search, etc), and uses the built in SQLCommand/SQLDataReader objects to do it, preferably calling stored procedures. For the 'get' type methods, they would then return your first set of classes (or lists of them).

This process will be more time consuming than using a framework/linqtosql, but you will not find another way that performs better than this, or is more flexible (since you're actually writing the code; it's not generated).

2008-11-19

相关问答

与其他DBMS一样，OrientDB需要您用作过滤器的属性的索引。 尝试执行此操作： CREATE INDEX Child.MarketName ON Chile( market name ) UNIQUE

而且你会看到你的查询现在应该<300ms。 有关更多信息， 请参阅https://orientdb.com/docs/2.2/SQL-Create-Index.html 。 Like any other DBMS, OrientDB requires an index on the prop

...

目前有大量的地图绘制工具可以帮助完成这项任务，但实际上就可维护性而言，您最好自己做(尤其是如果这种数据库模型不太可能改变)。 如果我处于您的情况，我会创建一些通用类来代表您在数据库中存储的内容，然后使用静态方法为您的数据层创建类。 每种方法只需完成一项应用程序需要的任务(即添加，编辑，获取，搜索等)，并使用内置的SQLCommand / SQLDataReader对象来执行此操作，最好调用存储过程。 对于'get'类型的方法，他们会返回你的第一组类(或者它们的列表)。 这个过程比使用framewo

...

如果存储过程做到了你想要的，我不得不说，我很怀疑你会通过扔掉它们并重新实现它们而获得好处。 此外，当需要将数据复制回主数据库时，使用存储过程或LINQ to SQL样式数据访问应该没有关系，因此担心您使用的DAL似乎是一个红鲱鱼。 关于有时连接的应用程序的棘手部分正在形成一个良好的冲突解决系统。 我的建议： 始终使用RowGuids作为表的主键。 如果您始终拥有唯一键入的新记录，合并复制效果最佳。 意识到合并复制只能做很多事情：将不同系统中的新数据放在一起很好 。 它甚至可以找出单方面的更新。 它

...

您所谈论的内容在测试期间非常有意义，但在生产代码中并不可行。 我的意思是......你可以在生产代码中做一些事情，例如确定LockCount和RecursionCount值(这是记录的)，从LockCount和presto中减去RecursionCount，你有＃个线程等待他们的手上CRITICAL_SECTION对象。 你甚至可能想要更深入。 SDK中记录了RTL_CRITICAL_SECTION_DEBUG结构。 对于这种结构，唯一有所改变的是，一些保留字段被赋予了名称并被投入使用。 我的意思

...

您返回false表示存在异常。 不建议这样做。 重新抛出它 catch(Exception e) {

//blah, maybe add some useful text to e

throw;

}

finally { //close up shop Although, look up what using does first incidentally }

然后处理它( catch (Exception e) { MessageBox.Show(("Error: " + e.Mess

...

如果使用存储库模式，则可以在不更改客户端的情况下更改存储实施。 例如，您可以将其设置为配置值(可能通过IoC容器注入)。 你没有解释任何关于你的业务逻辑或模型，所以这里有很多假设，但在你的客户端，在某些屏幕上是这样的： var dataToDisplay = _fooRepository.GetByID(42);

然后这个_fooRepository是一个IRepository ，其中实现可以是WCF客户端或实现接口的DbContext.DbSet包装器。 If you use

...

可能的原因：DAL项目中的类Sites不public 。 你只有...... class Sites

{

....

}

...这意味着该类是internal (与internal class sites相同)。 然后，您只能在DAL程序集中引用此类，而不能在另一个程序集中引用此类。 您需要public class Sites 。 Possible reason: The class Sites in your DAL project is not public. You have onl

...

这真的是基于意见的问题，但我在HighLoad ++会议上， Marco Cecconi是Stack Exchange开发人员之一，他的演讲Stack Overflow - 这完全 取决于 性能！ 。 正如你所知，stackoverflow是用ASP.NET MVC编写的，Marco说，SO项目在控制器中有简单的ADO请求。 他们这样写是因为性能。 当您有大量请求并创建许多中间对象(DAL模型，BL模型，ViewModel等)时，C＃GC会出现问题。 所以如果他们这样做是为了表现为什么你不能这样做

...