如何在没有 ORM 和嵌入式 SQL 的情况下设计 Java Web 应用程序 [英] How can I design a Java web application without an ORM and without embedded SQL

问题描述

原标题:关于使用 ORM 的好处的问题.

Original Title: Question about the benefit of using an ORM.

我想将 ORM 用于学习目的，并尝试使用 nhibernate.我正在使用教程，然后我有一个真正的项目.我可以走老路"或使用 ORM.我不确定我是否完全理解它的好处.一方面，我可以在代码中创建我的抽象，这样我就可以更改我的数据库并独立于数据库.另一方面，如果我真的更改数据库列，我似乎必须更改所有代码.

I want to use an ORM for learning purposes and am try nhibernate. I am using the tutorial and then I have a real project. I can go the "old way" or use an ORM. I'm not sure I totally understand the benefit. On the one hand I can create my abstractions in code such that I can change my databases and be database independent. On the other it seems that if I actually change the database columns I have to change all my code.

为什么我的应用程序没有 ORM，为什么不能更改我的数据库和代码，而不是更改我的数据库、orm 和代码?是不是他们的数据库结构变化不大?

Why wouldn't I have my application without the ORM, change my database and change my code, instead of changing my database, orm, and code? Is it that they database structure doesn't change that much?

我相信有真正的好处，因为 ORM 被很多人使用.我只是不确定我是否明白.

I believe there are real benefits because ORMs are used by so many. I'm just not sure I get it yet.

谢谢.

在教程中，他们有许多用于使 ORM 工作的文件

In the tutorial they have many files that are used to make the ORM work

http://www.hibernate.org/362.html

在应用程序发生变化的情况下，仅仅说我有适当的"抽象层似乎需要做很多额外的工作.因为我是新手，所以它看起来并不那么容易维护，而且似乎是额外的工作，而不是更少.

In the event of an application change, it seems like a lot of extra work just to say that I have "proper" abstraction layers. Because I'm new at it it doesn't look that easy to maintain and again seems like extra work, not less.

这是一个我不断回到的老问题.我想看看一个在没有 ORM、没有使用嵌入式 SQL 和没有使用 .NET LINQ-to-SQL 的情况下正确设计应用程序的示例，没有冒犯.我现在在 Java 世界中，我不知道如何继续.它是一个网络应用程序.没有 Spring，没有其他世俗的框架.JSP、JSTL、EL、HTML、JavaScript、CSS、Java、Tomcat.希望我没有遗漏任何东西.是的，我知道这是一个老问题.它仍然具有相关性.

This is an old question I keep coming back to. What I want to see if an example of properly designing an application without an ORM and without using embedded SQL and without using .NET LINQ-to-SQL, no offense. I'm in the Java world at the moment, and I'm lost on how to proceed. It is a web application. No Spring, no other worldly frameworks. JSP, JSTL, EL, HTML, JavaScript, CSS, Java, Tomcat. Hope I didn't leave anything out. And yes, I know it is an old question. It is still relevant.

推荐答案

为什么，哦，为什么，这个行业对这个概念的灾难如此执着?之前的答案都没有充分解决@johnny 的担忧.它们都是半生不熟的挥手理由，很好地避开了数据库程序员面临的具体问题.

Why, oh why, is the industry so wedded to this disaster of a concept? None of the previous answers adequately addresses @johnny's concerns. They are all half-baked hand-waving justifications that steer well clear of the concrete issues facing database programmers.

@TheTXI 的回答是我在问同一个问题时得到的典型回答:分层.那是什么意思?为什么我想要分离我的图层?或者，更重要的是，创建一个与关系层不同但应该是该层的规范映射的附加层对我有什么好处?

@TheTXI's answer is typical of the responses I get when asking the same question: separation of layers. What is that supposed to mean? Why do I want to separate my layers? Or, more to the point, how does it benefit me to create an additional layer that is different to the relational layer and yet is supposed to be a canonical mapping from that layer?

此外，(@johhny 尚未回答的观点)这如何保护我们免受变化?如果数据库发生变化，ORM 层几乎肯定要跟风.实际上，在对象级别不对连接表进行建模的默认做法使情况变得更糟，因为当表不可避免地增长了一些额外的列时，您不仅向对象模型添加了一些额外的字段，而且还更改了它的拓扑和强制一堆代码改写！这对变更管理来说是一场灾难，也是对关系(认为它们代表对象)的错误看法如何招致灾难的典型例子.如果您只是将关系数据库直接映射到编程语言中的全等概念(想想 LINQ-to-SQL，而不是 LINQ-to-EF)，就不会发生这种情况.

Furthermore, (@johhny's as-yet unanswered point) how does this protect us from change? If the database changes, the ORM layer will almost certainly have to follow suit. In fact, the default practice of not modeling join tables at the object level makes this even worse, because when the table inevitably grows some extra columns, you not only add some extra fields to the object model, but you also change its topology and force a bunch of code rewrite! This is a disaster for change management and is a classic example of how a misguided view of relations (thinking they represent objects) courts disaster. This simply wouldn't have occurred if you just mapped the relational database directly into congruent notions in the programming language (think LINQ-to-SQL, and not LINQ-to-EF).

这个领域最大的悬而未决的问题—房间里的大象—是:ORM 应该解决什么问题?并且不要说对象-关系阻抗不匹配".这只是另一个挥手的离去.解释为什么存在阻抗不匹配，以及为什么应该是数据库而不是语言进入数据库.我的解释是，大多数编程语言在表达和处理关系数据方面都很糟糕，但这是一个正在逐渐消失的历史现实(LINQ-to-SQL 是朝这个方向迈出的第一步)，而不是基本原则声音架构的基础.

The biggest unanswered question in this space — the elephant in the room — is: what problem is ORM supposed be solving? And don't say "object-relational impedance mismatch". That's just another hand-waving fob-off. Explain why there is an impedance mismatch, and why it should be the database that comes to the language rather than the language going to the database. My explanation is that most programming languages suck at expressing and working with relational data, but that this is a historical reality that is beginning to slip away (LINQ-to-SQL was the first baby-step in that direction), not a fundamental principle on which to base sound architecture.

ORM 变得如此复杂是有原因的，包括延迟加载、缓存、令人眼花缭乱的持久性和所有权语义等.还有一个原因是，尽管在键盘上进行了所有这些额外的敲击，但它们仍然无法有效地解决诸如哪对成员共享多个组?"之类的基本问题.关系模型是在网络和分层模型在这些问题的重压下屈膝屈曲的时候构思出来的；这是一股清新的空气.现在我们似乎都渴望回到我们满是猫尿的旧沙坑，我们认为我们已经发明了一些新东西(只要我们捂住鼻子).

There's a reason that ORMs have become so complex, with lazy-loading, caching, a bewildering array of persistence and ownership semantics, etc. And there's a reason that for all this extra pounding away at the keyboard, they still fail to efficiently solve basic problems like, "Which pairs of members share more than one group?" The relational model was conceived at a time when network and heirarchical models were buckling at the knees under the weight of such problems; it was a breath of fresh air. Now we all seem to yearn to go back to our old sandpit full of cat-pee, and we think we've invented something new (as long as we hold our noses).

(我完全希望对这个答案投反对票.但是当你这样做时请发表评论.我不介意被告知我错了，只要我知道为什么.)

(I fully expect to be liberally down-voted on this answer. But please leave a comment when you do. I don't mind being told I'm wrong, as long as I know why.)

感谢@Chris 抽出时间发表评论.它给了我一些需要解决的具体问题......(请注意，虽然我经常在下面提到 @Chris，但我并不是要让他专门负责；他的回答是我在讨论主题.所以我希望他不要将我的批评视为对个人的侮辱；他们不是故意的，我真的很感激他花时间做出回应.)

Thank you @Chris for taking the time to comment. It gives me some concrete points to address... (Note that while I frequently address @Chris below, I am not trying to take him to task specifically; his responses are typical of the kinds of comments I hear all the time when discussing the subject. So I hope he doesn't take my criticisms as a personal affront; they are not intended that way, and I do genuinely appreciate the time he took to respond.)

首先，让我澄清@Chris 的评论和回答中明显存在的一些误解.

First off, let me clear up some misconceptions evident in @Chris's comments and answer.

1. 出于所有显而易见的原因，我不提倡在代码中使用原始 SQL，还有一些不那么明显的原因(例如，SQL 既不是代数也不是微积分，这使得函数分解几乎不可能).
2. 我不提倡单体应用设计.一般来说，层是一件好事.
3. 我不提倡使用大量行噪声(例如特殊字段、方法和属性)来污染对象模型.然而，坦率地说，这是一个稻草人，因为域/对象模型只存在于 ORM 世界中.现在，我知道 LINQ-to-SQL 有所有这些类，其中有很多嘈杂的位，但它们只是幕后的管道；您无需编辑该代码，通常也不应该查看它.

现在一些反对的反对意见:

Now some objections to the objections:

1. 关于可以独立于数据库构建应用程序的断言是没有根据的.总的来说，ORM 只是到数据层的规范映射(表 Foo 和 Bar 变成了类 Foo 和 Bar，而表 FooBar 变成了类 Foo 和 Bar 之间的某种关系).此映射中没有太多回旋余地，因此对数据模型的任何更改几乎肯定都需要对对象模型进行相应的更改.在我看来，这是一件好事，因为一个与相应数据库模型完全不同的对象只不过是所有相关人员的额外维护难题.
2. 一旦摒弃了 ORM 导致数据模型独立的错觉，所有关于直接耦合到数据模型的弊端的抗议就变得毫无意义.但我想进一步探讨这一点，而不是简单地驳回它.耦合是系统设计的基本特征.在某些时候，必须做出决定和假设.您无法使用单个事物"表对所有内容进行编程.您必须确定您的域包含某些特定概念，然后创建尊重这些概念的模式和代码，将它们视为一等公民，对它们进行硬编码.应用程序应该独立于数据库的想法是错误的.数据库是(或应该是)业务知识的最纯粹表示(我知道情况并非总是如此，我稍后会解决这个问题).耦合到这种表示应该提供最强大的弹性保证，因为这样的数据模型只有在业务本身经历一些内在变化时才会发生变化.简而言之，与设计良好的数据库架构耦合是一件非常好的事情.
3. 分层本身并不是目的.这很好，因为它实现了一些特定的目标.前面的几点表明，以 ORM 的方式在数据库和应用程序之间进行分层对于实现弹性变化的真正目标既无效也没有必要.这是通过良好的数据库设计实现的.
4. @Chris 断言，让数据库决定事物会阻碍 OO 设计.这是事实，但只有当面向对象设计是建模知识的最佳方式时才有趣.OODBMS 在市场上几乎完全失败表明情况并非如此.关系模型以其谓词逻辑为基础，具有与面向对象设计相同的表达能力，而不会产生面向对象模型的图论复杂性.
5. @Chris 反对关系模型，理由是它不能解决当今的问题(因此是 NoSQL 运动)，这完全不合时宜.NoSQL 的意思是没有 SQL"，而不是没有关系模型".不幸的是，即使是 NoSQL 运动的支持者在这方面似乎也一无所知.SQL 有很深的缺陷，其中许多缺陷可以追溯到它与关系模型的彻底背离.说我们应该放弃关系模型，因为 SQL 很烂，这是一个相当公然的案例，把婴儿和洗澡水一起泼出去.
6. 未能使用 ORM 不会使构建应用程序的工作量增加三倍.这是一个荒谬的声明，甚至@Chris 似乎也在用对代码生成替代方案的反手恭维来打开它的后门.Codegen 工具(例如 LINQ-to-SQL 的 sqlmetal)是完美的解决方案，适用于不信奉应用程序数据模型绝对必须与数据库数据模型不同的教条的人.

1. The assertion that applications can be built independently of the database is unfounded. By and large, ORMs are just a canonical mapping onto the data layer (Tables Foo and Bar become classes Foo and Bar, and table FooBar becomes some kind of torrid affair between classes Foo and Bar). There isn't much wiggle room in this mapping, and so any change to the data model will almost certainly require a corresponding change to the object model. This is a good thing in my view, since an object that radically diverged from the corresponding database model would be nothing more than an additional maintenance headache for all concerned.
2. Once the illusion that ORMs engender data-model-independence is discarded, all protestations about the evils of direct coupling to the data model become moot. But I'd like to pursue this a little further than to simply dismiss it. Coupling is an essential feature of system design. At some point, decisions and assumptions have to be made. You can't program everything using a single "Things" table. You have to decide that your domain contains certain specific concepts and then create schemas and code that respect those concepts, treat them as first-class citizens, hard-code them. The idea that applications ought to be independent of the database is misguided. The database is (or ought to be) the purest representation of a business's knowledge (I know that this isn't always the case, and I will address this later). Coupling to this representation ought to provide the strongest guarantee of resilience, since such a data model will only change when the business itself undergoes some intrinsic change. In short, coupling to a well-designed database schema is a very good thing.
3. Layering is not an end in its own right. It is good because it achieves some specified goal. The preceding points show that layering between the database and the app in the way ORM does is neither effective nor necessary to achieve the real goal of resilience to change. This is achieved through good database design.
4. @Chris asserts that letting the database dictate things stymies OO design. This is true enough, but it is only interesting if OO design is the best way to model knowledge. The nearly complete failure of OODBMSs in the marketplace hints that this is not the case. The relational model, with its predicate-logic foundation, possesses the same expressive power as OO design without incurring the graph-theoretic complexities of OO models.
5. @Chris's objections to the relational model on the grounds that it doesn't solve today's problems (hence the NoSQL movement) is completely off the mark. NoSQL means "No SQL", not, "No relational model". Unfortunately even proponents of the NoSQL movement seem to be quite clueless in this regard. SQL has deep flaws, many of which can be traced to its radical departure from the relational model. To say that we should abandon the relational model because SQL sucks is a rather blatant case of throwing the baby out with the bathwater.
6. Failure to use an ORM does not triple the effort of building an application. This is a ludicrous claim, and even @Chris seems to be holding the back door open on it with a backhanded compliment to the codegen alternative. Codegen tools such as LINQ-to-SQL's sqlmetal are a perfect solution for anyone who isn't wedded to the dogma that the application's data model absolutely has to be different to the database's data model.

我自己使用 ORM 的经验是，它们在教程中效果很好，并在现实世界中引起了无尽的痛苦和挫折.由于 LINQ-to-SQL 解决了许多最初激发 ORM 的问题，我认为没有理由让自己遭受这种折磨.

My own experience with ORMs has been that they work great in tutorials and cause endless pain and frustration in the real world. With LINQ-to-SQL fixing many of the problems that motivated ORMs in the first place, I see no reason to put myself through that kind of torture.

仍然存在一个主要问题:当前的 SQL 数据库作物并没有对物理层和逻辑层的分离提供任何有意义的控制程度.从表到磁盘上的东西的映射在很大程度上是固定的，并且完全在 SQL DBMS 的控制之下.这不是关系模型计划的一部分，它明确地将两者分开，并允许定义一致的数据逻辑表示，这些数据可以以与逻辑模型所建议的完全不同的结构存储在磁盘上.例如，系统(或 dba)可以自由地进行物理非规范化 —出于性能原因——高度规范化的逻辑模型.由于 SQL 引擎不允许这种关注点分离，因此出于必要而对逻辑模型进行非规范化或以其他方式折磨是很常见的.因此，逻辑模型并不总是完全符合预期，因此无法完全实现使用数据库作为最纯粹的知识表示的理想.然而，在实践中，设计人员通常仍然坚持从数据库到领域模型的规范映射，因为其他任何事情都很难维护.

One major problem remains: the current crop of SQL databases doesn't offer any meaningful degree of control over the separation of physical and logical layers. The mapping from a table to stuff on the disk is largely fixed and entirely under the control of the SQL DBMS. This was not part of the plan for the relational model, which explicitly separated the two, and allowed for the definition of a consistent logical representation of data that could be stored on disk in a completely different structure than was suggested by the logical model. For instance, a system (or dba) would be free to physically denormalise — for performance reasons — a highly normalised logical model. Because SQL engines don't allow this separation of concerns, it is common to denormalise or otherwise torture the logical model through sheer necessity. As a result, logical models can't always be exactly as they should, and so the ideal of using the database as the purest representation of knowledge cannot be fully realised. In practice, however, designers generally stick to a canonical mapping from database to domain model anyway, because anything else is just too painful to maintain.

这篇关于如何在没有 ORM 和嵌入式 SQL 的情况下设计 Java Web 应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！