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

crud-table

在此博客文章中，我想介绍一下我如何使用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方法，该方法允许您作为用户创建用户，组，角色，使您可以在视图，实体（+属性）以及实体实例级别上分割应用程序。创建满足以下要求的应用程序（在这种情况下创建仅意味着：使用软件）没有问题。

纽约的经理看到纽约的所有客户
纽约销售人员会看到他们创建的纽约客户的所有详细信息。 SF客户仅显示属性“名称”和“城市”，其中只能编辑“名称”。
TX（总部）的经理可以从所有位置查看所有客户，但无法对其进行编辑

使用全面的UI来管理这些事情，几乎不需要实现本地的安全解决方案。

此功能列表可能会持续很长时间。我没有介绍报告部分，也没有介绍业务流程管理，计划的任务，HTTP-JSON API，Fat Client生成，不同的管理可能性等。我可能会在以后的博客文章中进一步介绍。

这一发现的实质

当看到所有这些不同的部分时，CUBA与编程框架的不同之处在于在这些技术框架之上添加了不同的“平台”功能。这些东西使程序员可以更加专注于业务问题。尽管这是不言而喻的，但这原则上是一件好事。

问题是，作为程序员，这通常很难想象。我们这些技术人员热衷于使用NTLM身份验证 ， 摆弄直到我们获得用于输入订单实例的完美用户界面 ，或为API创建超媒体驱动的RESTful HTTP接口 。我们想要创造事物，这完全是我们产业的基础。

换句话说，您可以从另一个角度看它。我们可能已经从Isacc Newton， Scott Hanselman或Sheldon Cooper那里知道：

我们都站在巨人的肩膀上

在软件开发领域尤其如此。从底层开始，像所有电气工程一样，主要的硬件抽象：操作系统，基于HTTP的网络协议，诸如关系数据库的数据存储机制，以及诸如Servlet，Rack和Rails的API和框架。所有这些使我们作为业务软件开发人员能够基本创建这些分布式，可伸缩且易于使用的生产力工具。

考虑到这一点，从字面上看，没有理由不提任何可能的抽象字母。显然，必须谨慎对待该一般建议。有很多充分的理由来使用C以及Plain Java Servlets或CUBA开发软件。

归结为这种“正确的工作工具”之类的东西。当您要创建典型的企业应用程序（指甲）并且附带此CUBA（锤子）时-非常合适。另一方面，这种含义不应让任何人认为，一切都是钉子。

我绝对建议你检查出CUBA尤其是不同的在线演示，你会发现在这里。

[编辑2015-10-30：添加了解释，CUBA是一种商业产品]

翻译自: https://www.javacodegeeks.com/2015/11/my-personal-crud-story-or-how-i-came-to-cuba-platform.html

crud-table