ORM架构 [英] ORM Architecture

问题描述

背景：我有一个项目，是不是在所有大型（每个像10页2 ASP.NET Web应用程序）。这两个Web应用程序共享很多后端的要求，特别是操纵一组约50桌的能力。他们都打同一个RDBMS，这将永远是MySQL的。

Background: I have a project that is not at all large scale (2 ASP.NET web applications with like 10 pages each). These two web applications share a lot of back-end requirements, specifically the ability to manipulate a set of around 50 tables. They both hit the same RDBMS, which will always be MySQL.

问题：一个大的功能丰富的ORM库（亚音速）加入到该项目一段时间回来，这原来只是太多。它太大了，有太多的地方，有太多的开销。 （我知道坏）的完成同样由亚音速采取> 1分钟产生创造一些集合，而原嵌入式查询取〜2秒。这不只是亚音速这就是问题所在，NHibernate和其它ORM工具只是太大的，有太多的功能，这将永远不会被使用。这些项目的范围将永远不会得到巨大的要么。此外数据库不可知论是不必要的，因为我们永远不会从MySQL切换出来，也没有人会使用这个工具，除了在内部。

Problem: A large feature-rich ORM library (Subsonic) was added to the project awhile back, which it turns out was just too much. It's too big, there's too many parts, there's too much overhead. Some Collections that are generated by Subsonic take >1min to create, whereas raw inline queries (bad I know) that accomplish the same take ~2s. It's not just Subsonic that is the problem, NHibernate and other ORM tools are just too big, with way too many features that will never be used. The scope of these projects will never get huge either. Also database agnosticism is unnecessary as we will never switch away from MySQL, and no one will ever use this tool except internally.

显然，内联查询是坏的，不安全的，错误的。 LINQ也是不是一个选项。因此，有必要进行一些较小的定制ORM工具对我来说，一个库包起来。我的想法是，包括：

Clearly inlining queries is bad, unsafe, wrong. Linq is also not an option. Thus there is a need for some small custom ORM tool for me to package up in a library. My thought is to include:

• 的基础是Table类，它的构造是刚刚喂一个数据库名和表名


• 表格类将暴露了一些方法公开


• 公开的DataRow记录（字符串primaryKeyValue）//获取一个记录


• 公共DataRowCollection记录（字符串whereClauseOrRangeOfKeyValues​​）//获取记录集合


• 公共BOOL保存（）//通过更新/插入任何已经改变的行存储数据库的当前状态;不是一定要保持哪些记录是脏与否
的最佳方法

• 加载（字符串primaryKeyValue）//公共BOOL讲述了一个给定的记录是否存在


• 公共DataRowCollection查询（字符串mysqlQuery）; //运行特定的自定义查询


• 私下会有pretty多只几件事情：消毒剂，做选择的方法，做upserts的方法和别的不多

也许计算器的汇集知识，可以突出这一基本设置的缺点或提供改进。先谢谢了。

Perhaps the pooled knowledge of StackOverflow can highlight shortcomings of this basic setup or offer improvements. Thanks in advance.

编辑：一个约束（不知道这是在这一点上是如何坚定）的是，我没有使用pre-建库。较高的UPS都因​​此受到亚音速关闭任何第三方工具很可能会被拒绝。因此，它更是结构的选择，而不是一个实用的选择。

One constraint (not sure how firm it is at this point) is that I not used a pre-built library. Higher ups are so turned off by Subsonic that any third party utility is likely to be rejected. So it's more of an architecture choice as opposed to a utility choice.

推荐答案

您的设置的问题是，它根本不手头解决这一问题。其中，顺便说一句，是与广大的ORM的问题之一。

The problem with your setup is that it simply doesn't address the issue at hand. Which, incidentally, is one of the problems with the majority of ORMs.

例如：

让我们假设你有一个项目表，你需要得到的项目，其状态为活动列表。你并不需要/想所有的领域，不仅仅是项目名称，状态之日起开始和最后更新日期。

Let's say you have a Projects table and you need to get a list of projects whose status is Active. You don't need / want all of the fields, just the project name, status, date started and last update date.

你如何完成在您的布局？在你的表类将无法正常工作一开始就（需要连接，仅表名），因为它会要求你把所有的列：这是你已经面临的问题。

How do you accomplish that in your layout? At the outset your table class won't work (requires connection and table name only) because it's going to require you to pull all of the columns: which is the problem you are already faced with.

这意味着你必须使用你的查询方法来获取只是你想要的东西。但是，怎么做表知道只改变单行时的状态栏你叫 .Save（）？现在，你是因为它需要另一个定制查询这是高性能变得非常复杂。或者，最起码，你必须实现更改每个列的跟踪，有你的引擎的足够聪明，只更新那些改变的值。

Which means you have to use your Query method to get just what you want.. However, how does table know to only change the status column of a single row when you call .Save()? Now you are getting really complicated because it requires yet another custom query for this to be performant. Or, at the very least, you'll have to implement change tracking on each column and have your engine be smart enough to only update those values that have changed.

现在考虑的是，绝大多数查询都是这样的。这意味着，你要拉，通常涉及联接跨越表格边框的记录，你不希望所有的列（由于性能原因），你的更新将会非常有针对性的...这是基于直接奥姆斯你的架构类的映射总是会失败的性能测试。

Now consider that the vast majority of your queries are like this. Meaning, you want to pull records that usually involve joins crossing table boundaries, you don't want all of the columns (for performance reasons), and your updates are going to be very targeted... This is where ORMs based on a direct mapping of your schema to classes will always fail the performance test.

那么，你该怎么办？我的看法是，你必须的数据访问，你正在做的类型分为两个逻辑操作的集合。一组将涉及以执行验证，并确保您的业务规则都在正常工作有常客OOP类。创造品牌新记录时，这些将被使用。

So, what are you to do? My opinion is that you have to split the types of data access you are doing into two logical sets of operations. One set will involve having regulars OOP classes in order to perform validation and ensure that your business rules are properly functioning. These will be used when creating brand new records.

有关下一组，你可以使用简单的数据表或动态类。写信给数据库并拉回你想要的记录。只要做一个更新，确保查询具有很强的针对性。您可以使用存储的特效或内联SQL做到这一点;哪个你更舒服。 小巧玲珑实际上是这种使用情况相当好，或只是使用企业与常规的SqlCommand库/ SqlConnections ..

For the next set you can use simple DataTables or dynamic classes. Send your query to the database and pull back the records you want. Whenever doing an update, make sure that query is highly targeted. You can accomplish this with stored procs or inline sql; whichever you're more comfortable with. Dapper is actually quite good for this use case or just use Enterprise Library with regular SqlCommand/SqlConnections..

点是，不建立自己的'ORM'，除非你明白与现有的问题。

Point is, don't build your own 'ORM' unless you understand the problem with existing ones.

这篇关于ORM架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！