我个人的CRUD故事-或我如何来到CUBA平台

在此博客文章中，我想介绍一下我如何使用CUBA平台以及此工具的好处。在我年轻的“业务应用程序开发”历史上，我将深入探讨不同的阶段，只为您提供一些背景知识。因此，让我们从如何进入典型的CRUD应用程序开始，以帮助非技术人员提高生产力。

关于我的CRUD背景的简短历史

多年来，我偶然发现了公司完全不同领域中的同类问题。从小商店到相当大的企业，人们通常都有一些基本的业务流程，应该加以实现。这些业务流程通常与输入数据并驾齐驱。

我在租车世界中首先遇到了这类要求。我工作过的一家公司开始在周末将小挖掘机出租给私人园丁。显然，他们想安排他们所拥有的一些挖掘机的租赁。

所以基本上这是领域：

具有客户-订单关系的域示例

每两本软件工程书中都会发现一个典型示例。

我们从访问数据库之类的东西开始就可以实现我们的目标。随着业务的增长，对软件的需求也随之增长。

从向用户显示在给定时间范围内租用了哪些产品的订单列表（我应该指出，这是一种非常糟糕的方式），我们想要实现某种更高级的计划视图。由于用户的位置不只一个，因此基于Web的软件似乎更有意义。因此，我开始了PHP之旅，那是当时的一个非常流行的选择。

但是真正让我感到奇怪的是这种情况，我不得不一遍又一遍地做同样的事情。因为除了实际的重要视图（如上面提到的调度视图）外，还有大量的视图和CRUD东西也必须实现。通常，没有人真正在乎这些屏幕，因为它不支持主要业务流程。但是，产品，租用地点，用户，角色和所拥有的东西也都希望由用户创建和管理。

在停留在PHP世界中之前（这很早就出现在不同的Framework上，或者至少是“引起我的注意”）–因此，我真的要使用HTML，PHP， PEAR等“裸机”和其他疯狂的东西，例如script.aculo.us 。

脚手架救援

快进-几年，然后进行CRUD项目。由于计算机科学的研究主要以Java形式进行，因此面向对象是我想到的所有方面。看来我已经准备好迈出下一步。正如我们大多数人所知道的那样，用Java做基于Web的软件比痛苦更不是痛苦。因此，我环顾四周以摆脱过去几年中制作的旧PHP东西。

在此期间，博客上的新孩子是Rails。诸如CoC ，数据库迁移等引入的Web应用程序概念对我来说非常令人惊讶。但是有一件事是令人大开眼界的：脚手架。要从定义业务对象的模型出发，从数据库定义到HTML表单以及“ RESTful API”生成完整的堆栈，这是非常必要的。这让我改变了主意，“我必须以编程方式创建什么，软件/框架/生成器应该为我做什么”。

软件行业的普遍共识是，现在和现在仍然是，必须谨慎对待这些脚手架机制。这种癫痫症的原因是多方面的。一件事是，“它不适用于实际应用程序”。另一个经常听到的消息是“结果UI不符合我们的要求”。

一个由Grails生成的作者和书籍的脚手架示例。

考虑时，这是绝对正确的。因为有了（G）Rails之类的框架，您便拥有了通用工具。这意味着它不直接与某些类型的应用程序绑定。您可以创建具有高度优化的ui的在线商店，就像可以实现各种应用程序一样为基于Javascript的胖客户端创建RESTful HTTP后端。您可以像企业应用程序一样执行CRUD，就像为公司的营销活动创建响应式网站一样。

Web应用程序世界中可实现的应用程序空间

因此，脚手架不能解决所有这些问题，因为范围太宽。这就是为什么这些脚手架尝试的结果会以域类型的CRUD接口结束的原因，从UI的角度以及功能上来看，域类型都有一定的局限性。完全可以，因为这些框架的重点从来没有放在支架的方面。

“特定于域”取决于角度

尽管我说过，Rails都是通用的 ，但Martin Fowler 告诉我们这不是通用的 ，而是特定于领域的 。我是谁，他是最初的敏捷宣言的一部分，是重构的作者，是Refactoring的作者，还有很多其他好东西，这推动了软件行业的发展？

问题是， 特定领域是一个非常通用的术语。从Java Servlets的角度来看，Rails绝对是特定于域的，该域是“带有关系数据库后端的Web应用程序”。对于更通用的Spring MVC与基于Spring（MVC）的全栈Framework Grails，也是如此。另一方面，Java Servlet比使用套接字更加具体，因为您受HTTP约束。

从通用到特定于Web开发领域的领域

当我在图的第二层中的这些框架中创建大多数像CRUD的业务应用程序时，我认为如果存在一类框架/平台，该方案可以更好地满足业务应用程序的要求。当我们将关注点进一步缩小到这部分应用程序时，脚手架可能会创造出真正可用的东西。

几个月前，我通过Java代码极客的一篇文章了解了CUBA平台。 CUBA主要是一个商业“框架”，它的口号是：“一个用于加快企业软件开发速度的高级Java框架”。

乍一看，它看起来就像是另一个具有共同部分的Web框架。 OR-Mapper，依赖注入，脚手架，UI等。与其单独创建所有子部分，不如使用Grails一样，它使用一种元框架方法。 OR-Mapper是JPA（EclipseLink），Spring for DI，Vaadin作为UI框架。

通用的新类别–特定领域的维度？

在深入研究之后，我意识到，这件事似乎与我之前在Web开发领域中看到的有些不同。

所不同的是，CUBA的作者走的是“特定领域”之路，正如我在上图中所想到的那样，确实专注于缩小“企业软件开发”的范围。考虑到这一点，作者能够提出更多的意见。固执己见的框架通常会提高生产力（如果您遵循生活方式）（就像Rails世界中的“ The Rails way ”一样）。

CUBA平台似乎也是如此。自从我第一次使用Rails来支持PHP / Java以来，遵循他们对过滤，安全性，报告等内容的意见就极大地提高了生产率。

短语“快速应用程序开发”在这里确实具有另一个含义。这是由于多种原因。

是什么让这

业务应用程序的域模型通常具有许多实体以及它们之间的连接。这将导致一个UI，您必须在其中创建实际工作流程中的许多相关实体。

首先，他们完全正确地获得了业务应用程序所需的基本内容。 CUBA创建了一个可以完全满足这些需求的脚手架UI。它基于他们为两个实体可以具有的不同样式的关联做出的不同选择。 一对多或一对一关联通过PickerField表示，“ 多对多”关联为关联创建一个添加/删除表，而“ 一对多”关联将在实体的详细视图中创建一个表，该表包含一个侧。

使用这些简单但令人难以置信的强大工具，您可以在数分钟内用相似的复杂UI创建一个非常复杂的域模型，这使通过UI创建相关实体的图变得很高兴。

第二部分是通用过滤器解决方案。感觉有点像您可以从Excel的附加功能中了解到的过滤可能性，您可以过滤表所基于的实体的关联。这真是太神奇了，并且不需要开发人员手动创建的大量自定义过滤器编程。

接下来，有一个完整的安全子系统。它基于ACL方法，该方法允许您作为用户创建用户，组，角色，使您可以在视图，实体（+属性）以及实体实例级别上分割应用程序。创建满足以下要求的应用程序（在这种情况下创建仅表示：使用软件）没有问题。