现代信息技术以其强大的功能令人叹为观止，它们被开放的机会所淹没，其内在的技术完美使他们不满意，但是IT一次又一次地折磨它是一个荒谬的观点。 显示数据库中的用户数据，从他那里获取输入，然后将其放回数据库中，显示结果。 输入字段，按钮，复选标记，题词-似乎它们是如此的复杂，以至于需要在模板引擎之上的框架引擎之上，在编译器框架之上的框架之上构建诸如框架之类的难题结构？ 以及为什么尽管付出了巨大的努力，我们仍然可以轻松愉快地制作教程中的玩具示例，但是，一旦工具包遇到了现实生活中的真实任务……怎么说更柔和……随着要解决的任务的复杂性不断增加，非线性就变得很强烈实施困难。 嗯，这将是一个在理论物理学或太空技术水平上真正令人困惑的问题，因为无论如何都没有按钮和复选标记。 为什么这种胡言乱语数十年来继续毒害公民和集体劳动者的生活？
一如既往，原因可能很多。 也许所有这些都应该以一种或另一种方式进行考虑，但是在这里和现在，我们将讨论对象关系映射（ORM）任务，该任务始终以某种形式出现在这些“按钮和复选标记”中。
我们对ORM有什么了解
- 将数据存储在关系表中并不是说这是一件很简单的事情，但是总的来说，其思想和应用方式都非常清楚并且经过了充分的研究。
- 对于对象编程，并不是一切都那么好（有几种竞争方法），但是总的来说，随着技术的实现和应用，一切也都差不多了。
- 关于数据，它们的存储和处理，以及两者。 那实际上是关于同一件事。
- 在我们看来，两个世界之间应该有一个简单，可理解，方便，可预测和通用的桥梁。
- 每次我们都容易找到这座桥梁时，不幸的是，它的简单性，可理解性，便利性，可预测性和普遍性超出了教程中的简单示例。
- 每个人都会遭受苦难：必须要做很多非常无聊的工作的开发人员，以及必须与笨拙的软件和业务作斗争的用户，而业务的需求突然变得难以忍受的漫长和昂贵，乃至整个行业。
- 我见过许多不同的ORM，但没有见过任何好的ORM。 也就是说，除了简单的例子之外，它不会变成负担和Procrustean床。
为什么一切都如此诡异
关系数据库的理论和实践的思想基础是谓词演算，即数学的一个分支。 对于OOP，那里缺乏类似的意识形态基础。 可以这样尝试表达OOP的基本思想：由于世界是由对象组成的，因此可以通过在软件系统内创建对象来对此世界建模，这一点很方便。 从这个意义上讲，一次出现两个错误。 首先，世界本身并不由物体组成，也从未由物体组成。 其次，对不起，但是为什么程序必须模拟世界呢？ 就是说，我们有一个概念上不正确的陈述，完美地补充了对该问题的无意义的陈述。
每个ORM都试图根据便利性，历史悠久的方法以及通常是传说，权威人士的观点和简单的误解来清楚地扩展实际上是数学分支和宽松的各种实践之间的统一对应关系。 可以使其在体外起作用，但在体内注定看起来可悲，带来的悲伤多于喜悦。
论面向对象的必然性
尽管如此，对我们软件的面向对象的需求是我们不可避免的现实。 这种必然性主要基于这样一个事实，即对对象进行操作是我们任何活动的本质和基础。 这个世界本身不是由对象组成的，但是为了理解这个世界上的东西并对该世界做点什么，我们自己将其部分声明为对象，称它们为名称，尝试理解它们的行为，并应用于他努力取得预期的结果。 这是我们的运作方式，不可能离开它，也没有必要。 一切都是对象，不是因为它确实是对象，而是因为我们不能这样做。 绝对不能成为对象的事物完全超出了我们理解能力的范围，并且不能作为我们努力的主题。
即使程序是在没有使用OOP技术的情况下编写的，它也不可避免地包含对象（从广义上讲），通过操纵开发人员解决其问题的对象-变量，数据类型，运算符，算法，句法构造，函数，模块。 从用户的角度来看，该程序还具有一组与之交互的对象-按钮，标签，输入字段，页面，站点以及整个系统。
我们存储在数据库中的内容
如上所述，关系数据库基于谓词演算。 谓词由事实构成，在我们的情况下，存储在介质中。 以防万一，我注意到关系数据库不仅是关于外键之间的表关系，而且关系不大。 用恰当的术语来说，关系就是我们简称为表的东西。 也就是说，即使您的数据库只有一个带有两列的表（例如，名称和电话号码），您也已经具有一个关系数据库，该关系数据库可以建立两组名称和电话号码之间的关系。
关系数据库不存储对象；它存储事实。 存储的事实当然有一个对象（“这个事实是关于什么？”），当我们尝试教系统回答这个问题时，我们就有实体，即与事实相关联的对象。 如果您能正确地工作，我们的基础结构就源于对“我们打算保留什么样的事实？”这个问题的一系列答案。只有在下一个阶段，我们才能得到类似于使事实成为客观性的对象的东西。 当然，您可以“从对象”设计，但是我不建议这样做，除非在实验室工作中与数据库设计没有直接关系的主题。 严重的体系结构错误计算的危险太大。 另外，这至少是不方便的。
关于对象数据库的一点题外话。 一个很简单的想法：如果我们厌倦了ORM的问题，那么也许我们应该对“ R”部分做些什么？ 让我们的数据库不是一个艰难而苛刻的关系怪物，而是一个专门为存储对象量身定制的时尚青年。 例如，某种基于NoSQL的示意图。 但是最后，突然发现类似NoSQL的ORM比老式的旧SQL-one更尴尬和不自然。 无论如何，我们可以愉快地运行无电路的DBMS，但实际上没有无电路的数据。 对于无回路数据库，没有比ORM更无助，不负责任和不道德的了。
好ORM
一个好的ORM是缺少的ORM。 好吧，认真。 查看您的任何ORM系统，并诚实地尝试回答您的问题：这个怪物有什么好处？ 除了未兑现的幸福承诺和一再受偏见的信誉低下的承诺外，使用它的原因是什么？ 当然，有一些有用的方便的东西，但是在不断出现的引入的建筑变形和性能问题的背景下，它们又是什么呢？
通常，“低级”数据库API简单，方便，完整且一致。 通常，足够多的手指可以列出所有功能。 学习他们不是上帝新闻的任务。
我将尝试草绘一组体系结构原理，这些原理使您无需使用ORM就可以将对象映射到数据库：
- 我们存储事实，对对象进行操作。 请记住，数据库存储事实，而数据处理中涉及的对象模型是从不同角度对事实集的投影。 例如，对于具有名称和电话号码的给定示例，我们可以拥有Abonent类（可以存储多个号码）和PhoneNumber类（可以为其设置多个订户）（别忘了，除了个人移动电话号码，我们还有那里仍然有公寓和办公室电话）。 数据库中的表仅仅是定义许多名称和电话号码之间的多对多关系的表。 只是两个不同的预测。 顺便说一下，这种方法通常可以扩展到更复杂的情况，从而使您可以在系统中使用诸如“根据给定条件组合在给定时期内的平均销售额”之类的有用类。
- 通过面向问题的API将事实投射到对象中，反之亦然。 没有应用声称是通用的解决方案。 如果您仍然不知道如何编写便捷的API，请学习如何。 重要的是，要教自己立即记录下来。
- 首先订购。 如果您将DBMS的经典版本与严格的数据方案一起使用，则该方案本身会使处理数据的工作变得井然有序。 由对象的结构编码的额外结构只是多余的。 如果您使用无模式的DBMS，那么由于不同的开发人员对存储的内容有不同的想法，因此您当然必须做出一些努力以确保数据库不会变成垃圾。
- DBMS独立性（如有必要）。 如果对您而言，ORM最有趣的属性是DBMS独立性，那么请使用诸如ODBC，JDBC，ADO之类的特殊工具，或者如果无法实现，请进行自己的抽象级别。 它并不像刚开始看起来那样困难。 您不需要为您的任务提供绝对所有DBMS的绝对所有功能，对吗？
- 不要忘记处理数据的其他方面。 例如，共享对数据的访问（可以任意复杂），监视，复制等等。 但是在这里，我对您有个好消息：因为在您最喜欢的ORM中，添加了。 该方面仍按照“您不会取悦所有人，吃您所提供的东西”的原则实施，拒绝您必须付出更多努力而不是与之合作的可疑服务最终将证明是战略上正确的决定。
合计
ORM对我们行业是一个非常痛苦的话题。 在云人工智能推动量子区块链发展的时代，绝大多数员工正在忙于将业务逻辑和用户界面连接到数据库。 创意过程伴随着数以百万计的可怕代码，显微镜下的钉子，痛苦和绝望。 这种令人沮丧的状况的根源之一是，人们始终存在着一个普遍存在的误解，即普遍的ORM原则上是可能的。 但这是不可能的，并且有一个根本原因无法消除。 意识到这一事实是摆脱这一噩梦的第一步。 有一个出路，有其他选择，但是首先您需要意识到，感受和学习以保持注意力的集中。
PS致以诚挚的敬意，他们为投入大量时间和精力在ORM领域创造了众多全球最佳产品而付出了很多时间和精力。 真的很抱歉