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

问题描述

编辑：原始标题：关于使用ORM的好处的问题。

我想使用ORM进行学习，我尝试使用nhibernate。我正在使用教程，然后我有一个真正的项目。我可以去老路或使用ORM。我不知道我完全明白了好处。一方面，我可以在代码中创建我的抽象，以便我可以更改我的数据库，并且与数据库无关。另一方面，如果我实际上更改了数据库列，我必须更改我的所有代码。

为什么我的应用程序没有ORM，改变我的数据库和更改我的代码，而不是改变我的数据库，orm和代码？是否它们的数据库结构不会有太大变化？

我相信有真正的好处，因为ORM被这么多使用。我只是不确定我得到它。

谢谢。

编辑：在教程中有许多用于使ORM工作的文件

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

如果应用程序更改，似乎很多额外的工作只是说我有正当的抽象层。因为我是新的，它看起来不那么容易维护，再次似乎是额外的工作，而不是更少。

编辑：这是一个我保留的一个旧问题回来我想看看如果正确设计一个没有ORM的应用程序并且不使用嵌入式SQL，而不使用.NET LINQ to SQL的例子，那就没有任何意义。我现在在Java世界，我失去了如何进行。它是一个Web应用程序。没有春天，没有其他世俗的框架。 JSP，JSTL，EL，HTML，JavaScript，CSS，Java，Tomcat。希望我没有留下任何东西。是的，我知道这是一个老问题。它仍然是相关的。

解决方案

为什么，哦，为什么行业如此陷入这个概念的灾难？以前的答案都没有充分地解决@ johnny的担忧。他们都是半熟的手捧理由，从而避免数据库程序员面临的具体问题。

@ TheTXI的答案是我在询问同样的问题：分层。这是什么意思？为什么我想要分隔我的图层？或者，更重要的是，如何创建一个不同于关系层的附加层，但是它应该是那个层的规范映射呢？

<另外，（@ johhny还没有回答）这是如何保护我们免受变化的？如果数据库发生变化，ORM层几乎肯定也要跟随。实际上，在对象级别不建模连接表的默认做法使得更糟糕的是，因为当表不可避免地增加了一些额外的列时，您不仅向对象模型添加了一些额外的字段，而且还改变了其拓扑和强制一堆代码重写！这是变革管理的灾难，而且是一个经典的例子，说明了一个误导性的观点（认为它们代表物体）是法庭的灾难。如果您将关系数据库直接映射到编程语言中的一致概念（请参阅LINQ to SQL，而不是 LINQ-to-EF），那根本就不会发生。

这个空间中最大的未回答的问题—房间里的大象—是：ORM应该解决什么问题？而不要说对象关系阻抗不匹配。这只是另一个挥手的手势。解释为什么存在阻抗不匹配，为什么它应该是数据库到语言而不是数据库的语言。我的解释是，大多数编程语言吸引了关系数据的表达和使用，但是这是一个开始消失的历史现实（LINQ to SQL是朝着这个方向迈出的第一步），而不是基本原理基于声音架构的基础。

有一个原因是ORM变得如此复杂，懒惰加载，缓存，令人难以置信的持久性和所有权语义等等。还有一个原因，就是键盘上这些额外的冲击，他们仍然无法有效地解决基本问题，如哪一对成员共享多于一个组？当网络和阴性模型在这些问题的重要性下屈膝时，构想了关系模型;这是一阵清新的空气。现在我们似乎都渴望回到我们老旧的沙坑里，我们认为我们发明了一些新的东西（只要我们拥有我们的鼻子）。

（我完全希望在这个答案中被自由地投票，但是请你留言，我不介意被告知我错了，只要我知道为什么。）

编辑：谢谢@Chris花时间评论。它给了我一些具体要点来解决...（请注意，虽然我经常在@Chris下面讨论，我不是试图让他具体的任务;他的回答是我听到的那些典型的评论，我一直在讨论所以我希望他不把我的批评当作个人的侮辱，而不是这样的意思，而且我真的很感激他的回应。）

首先，让我清除@ Chris的评论和答案中的一些误解。

1. 我不主张代码中的原始SQL，因为所有明显的原因，有些并不那么明显（例如，SQL既不是代数也不是微积分，这使功能分解实际上是不可能的）。


2. 我不主张单片应用程序设计。一般来说，层是一件好事。


3. 我不主张污染具有很多线噪声的对象模型，如特殊字段，方法和属性。然而，坦白说，这是一个稻草人，因为域/对象模型只存在于ORM领域。现在，我知道LINQ-to-SQL具有所有这些类，其中有很多嘈杂的位，但它们只是幕后管道;你不要编辑这个代码，你通常不应该看看。

现在有一些反对意见： / p>

1. 可以独立于数据库构建应用程序的断言是毫无根据的。总的来说，ORM只是数据层上的规范映射（表Foo和Bar成为Foo和Bar类，表FooBar成为类Foo和Bar之间的一种热情）。这个映射没有太多的摆动空间，所以对数据模型的任何改变几乎肯定需要对对象模型进行相应的改变。这在我看来是一件好事，因为从相应的数据库模型彻底分歧的对象只不过是所有有关的维护头痛。


2. 一旦ORM产生错觉数据模型独立性被丢弃，所有关于直接耦合到数据模型的邪恶的抗议都变得模糊。但是，我想追求这一点比简单地解除它更远。耦合是系统设计的一个基本特征。在某些时候，必须做出决定和假设。您无法使用单个事件表来编程所有内容。您必须确定您的域包含某些特定的概念，然后创建符合这些概念的模式和代码，将其视为一流公民，对其进行硬编码。应用程序应该独立于数据库的想法被误导。数据库（或者应该是）企业知识的最纯粹的代表（我知道这并不总是这样，我稍后会解释）。与这种代表联系应该提供最强的弹性保证，因为这样的数据模型只会在企业本身发生内在变化时才会发生变化。简而言之，与精心设计的数据库模式的耦合是一件非常好的事情。


3. 分层不是自己的结局。这是很好的，因为它实现了一些特定的目标。上述观点表明，以ORM的方式，数据库和应用程序之间的分层既不能有效也不必要，以达到恢复变革的真正目标。这是通过良好的数据库设计来实现的。


4. @Chris声称，让数据库规定了OO设计的障碍。这是真的，但是只有OO设计才是知识建模的最佳方式，这是有趣的。 OODBMS在市场上几乎完全失败，暗示不是这样。关系模型与其谓词逻辑基础具有与OO设计相同的表现力，而不会导致OO模型的图论理论复杂性。


5. @ Chris反对关系模型理由是它不解决今天的问题（因此NoSQL运动）完全脱离了标准。 NoSQL意味着无SQL，而不是没有关系模型。不幸的是，即使NoSQL运动的支持者似乎在这方面也没有任何意义。 SQL有深刻的缺陷，其中许多可以追溯到其关系模型的根本偏离。说，我们应该放弃关系模型，因为SQL吸吮是一个相当公然的案例，用沐浴水扔婴儿。


6. 不使用ORM不构建应用程序的三倍。这是一个荒唐的声明，甚至@Chris似乎正在拿着后门打开它，对代码替代的反手恭维。如LINQ-to-SQL的sqlmetal这样的Codegen工具是一个完美的解决方案，适用于任何不符合教条的人，即应用程序的数据模型绝对与数据库的数据模型不同。

我自己的ORM经验一直是，他们在教程中工作得很好，并在现实世界中造成无尽的痛苦和沮丧。使用LINQ to SQL解决了许多激励ORM的问题，我看不出有理由让自己受到这种折磨。

一个主要问题遗骸：当前的SQL数据库不会对物理层和逻辑层的分离提供任何有意义的控制。从表到磁盘上的东西的映射在很大程度上是固定的，完全由SQL DBMS控制。这不是关系模型的计划的一部分，它明确地分离了两个，并且允许定义可以以与逻辑模型所建议的完全不同的结构存储在磁盘上的数据的一致的逻辑表示。例如，一个系统（或dba）可以自由地进行物理上的非规范化出于性能原因—高度归一化的逻辑模型。因为SQL引擎不允许这种分离的关注，通常是通过纯粹的必要性对逻辑模型进行非规范化或其他折磨。因此，逻辑模型并不总是完全符合要求，因此使用数据库作为最纯粹的知识表达的理想无法完全实现。然而，实际上，设计师通常坚持从数据库到域模型的规范映射，因为任何其他事情都太难以维护。

EDIT: Original Title: Question about the benefit of using an 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.

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?

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

Thank you.

EDIT: 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.

EDIT: 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.

解决方案

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'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?

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).

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.

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.)

EDIT: 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.)

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

1. I do not advocate raw SQL in code, for all the obvious reasons, and some not so obvious ones (e.g., SQL is neither an algebra nor a calculus, which makes functional decomposition virtually impossible).
2. I do not advocate monolithic application design. Layers are, in general, a good thing.
3. I do not advocate polluting object models with lots of line-noise such as special fields, methods, and attributes. Frankly, however, this is a strawman, since domain/object models only exist in the ORM universe. Now, I know LINQ-to-SQL has all these classes with lots of noisy bits in them, but they are just behind-the-scenes plumbing; you don't edit that code, and you generally shouldn't even look at it.

Now some objections to the objections:

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.

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.

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的情况下设计Java Web应用程序，而不需要嵌入式SQL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！