从数据库生成 UI - 好的、坏的和丑陋的？
我在某处读过一个声明，从数据库布局（或业务对象，或任何其他业务层）自动生成 UI 是一个坏主意。 我还可以想象为了做出这样的事情，人们必须面对一些好的挑战。
然而，我还没有看到（也找不到）任何人们尝试这样做的例子。 因此我想知道——事情真的有那么糟糕吗？ 这绝对不容易，但能否取得任何成功呢？ 主要障碍是什么？ 很高兴看到一些成功和失败的例子。
为了澄清 - “自动生成 UI”我的意思是所有表单及其所有控件都是完全自动生成的（在运行时或编译时），可能基于元数据中有关如何表示数据的一些提示。 这与手工设计表单（就像大多数人所做的那样）形成鲜明对比。
已添加：发现这个有点相关的问题
添加2：好的，似乎获得相当公平结果的一种方法是是否有足够的与演示相关的元数据可用。 对于这种方法，多少才算“足够”？它会比手动设计表单更少工作吗？ 它是否也为未来的变化提供了更大的灵活性？
I've read a statement somewhere that generating UI automatically from DB layout (or business objects, or whatever other business layer) is a bad idea. I can also imagine a few good challenges that one would have to face in order to make something like this.
However I have not seen (nor could find) any examples of people attempting it. Thus I'm wondering - is it really that bad? It's definately not easy, but can it be done with any measure success? What are the major obstacles? It would be great to see some examples of successes and failures.
To clarify - with "generating UI automatically" I mean that the all forms with all their controls are generated completely automatically (at runtime or compile time), based perhaps on some hints in metadata on how the data should be represented. This is in contrast to designing forms by hand (as most people do).
Added: Found this somewhat related question
Added 2: OK, it seems that one way this can get pretty fair results is if enough presentation-related metadata is available. For this approach, how much would be "enough", and would it be any less work than designing the form manually? Does it also provide greater flexibility for future changes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我们有一个项目可以生成数据库表/存储过程以及业务类的 UI。 它是在 .NET 中完成的，我们在类和属性上使用了很多自定义属性，以使其按照我们想要的方式运行。 不过它效果很好，如果您设法遵循您的设计，您可以非常轻松地创建软件的定制。 我们也确实有一种方法可以在一些非常特殊的情况下放入“自定义”用户控件。
总而言之，这对我们来说效果很好。 不幸的是，它是一种出售的银行产品，没有可用的来源。
We had a project which would generate the database tables/stored proc as well as the UI from business classes. It was done in .NET and we used a lot of Custom Attributes on the classes and properties to make it behave how we wanted it to. It worked great though and if you manage to follow your design you can create customizations of your software really easily. We also did have a way of putting in "custom" user controls for some very exceptional cases.
All in all it worked out well for us. Unfortunately it is a sold banking product and there is no available source.
对于一些很小的东西来说这是可以的，你所需要的只是一种实用的方法来获取数据。
但是对于任何类似于真实应用程序的东西来说，这是一个糟糕的主意。 良好的用户界面的关键在于人性化因素，即通过调整来确保机器对人的触摸做出良好反应的部分。
当你的界面是机械生成的时候你就无法得到这一点......也许是接近人工智能的东西。 :)
编辑 - 澄清一下：从 code/db 生成的 UI 作为起点很好，它只是一个垃圾终点。
it's ok for something tiny where all you need is a utilitarian method to get the data in.
for anything resembling a real application though, it's a terrible idea. what makes for a good UI is the humanisation factor, the bits you tweak to ensure that this machine reacts well to a person's touch.
you just can't get that when your interface is generated mechanically.... well maybe with something approaching AI. :)
edit - to clarify: UI generated from code/db is fine as a starting point, it's just a rubbish end point.
嘿，这并不难实现，而且也不是一个坏主意。 这完全取决于您的项目需求。 许多软件产品（请注意，不是项目，而是产品）都依赖于这种模型 - 因此他们不必针对不同的客户需求重写代码/用户界面逻辑。 客户可以按照他们想要的方式自定义他们的用户界面，在管理系统中使用设计器表单，
我已经使用 xml 来保存此类内容的元数据。 我为每个字段保存的一些属性是：
下拉列表/多复选框列表）
列表，如果没有，则下拉列表）
关于定位 - 我不太关心，只是在下面生成表 tr td 标签 1其他 - 但是如果你也想实现这个，你可以再有 1 个名为 CssClass 的属性，你可以在这里定义 ui 特定的属性（外观、感觉、定位等）
更新：还请注意很多电子商务产品都遵循这种类型当您想要输入产品信息时，动态用户界面 - 因为他们的客户可以销售从家具到性玩具的所有东西；-) 因此，他们不需要为每个不同的行业重写代码，而是让客户通过以下方式输入产品属性的元数据：管理表单:-)
我还建议您查看 Entity-attribute-value 模型 - 它有自己的优点和缺点，但我觉得它可以很好地满足您的要求。
hey this is not difficult to achieve at all and its not a bad idea at all. it all depends on your project needs. a lot of software products (mind you not projects but products) depend upon this model - so they dont have to rewrite their code / ui logic for different client needs. clients can customize their ui the way they want to using a designer form in the admin system
i have used xml for preserving meta data for this sort of stuff. some of the attributes which i saved for every field were:
down list / multi check box list)
list, if no then drop down list)
regarding positioning - i did not care much and simply generate table tr td tags 1 below the other - however if you want to implement this as well, you can have 1 more attribute called CssClass where you can define ui specific properties (look and feel, positioning, etc) here
UPDATE: also note a lot of ecommerce products follow this kind of dynamic ui when you want to enter product information - as their clients can be selling everything under the sun from furniture to sex toys ;-) so instead of rewriting their code for every different industry they simply let their clients enter meta data for product attributes via an admin form :-)
i would also recommend you to look at Entity-attribute-value model - it has its own pros and cons but i feel it can be used quite well with your requirements.
在我看来，您应该考虑一些事情：
好吧，我认为你应该考虑这些的原因很明显。 这种模型是否有意义实际上取决于您的项目......
如果您想创建一些可以在运行时自定义的表单，那么这个模型可能非常有用。 另外，如果您需要做很多较小的工具并将其用作某种“引擎”，那么这种努力可能是值得的，因为您可以节省大量时间。
使用这种“渲染引擎”，您可以自动添加错误报告、检查值或添加始终使用相同模式构建的其他内容。 但如果你有太多这样的东西、元素或属性，那么性能会迅速下降。
在更大的项目中变得有趣的另一件事是，必须在每种形式中发生的更改只需要在引擎中进行，而不是在每种形式中进行。 如果完成的应用程序中存在错误，这可以节省大量时间。
在我们公司，我们在现金软件（现在我不记得正确的词......）和我们的应用程序之间使用类似的模型来创建界面生成器，只是它不创建 UI，而是创建一个输出文件之一应用程序。
我们使用 XML 来定义结构以及值需要如何转换等等。
In my Opinion there some things you should think about:
Okay, i think that its pretty obvious why you should think about these. It really depends on your project if that kind of model makes sense...
If you want to create some a lot of forms that can be customized at runtime then this model could be pretty uselful. Also, if you need to do a lot of smaller tools and you use this as some kind of "engine" then this effort could be worth it because you can save a lot of time.
With that kind of "rendering engine" you could automatically add error reportings, check the values or add other things that are always build up with the same pattern. But if you have too many of this things, elements or attributes then the performance can go down rapidly.
Another things that becomes interesting in bigger projects is, that changes that have to occur in each form just have to be made in the engine, not in each form. This could save A LOT of time if there is a bug in the finished application.
In our company we use a similar model for an interface generator between cash-software (right now i cant remember the right word for it...) and our application, just that it doesnt create an UI, but an output file for one of the applications.
We use XML to define the structure and how the values need to be converted and so on..
我想说的是，大多数情况下数据不适合 UI 生成。 这就是为什么您几乎总是在中间放置一层逻辑来向用户解释数据库信息。 另一件事是，当您从数据库生成 UI 时，您最终将显示系统的内部工作原理，这是您通常不想做的事情。
但这取决于数据库来自哪里。 如果它的创建是为了准确反映系统的用户目标。 如果用户关于应用程序应该帮助他们的心智模型存储在数据库中。 那么它可能就会起作用。 但是，您必须从用户端开始。 如果不是我建议你不要走那条路。
I would say that in most cases the data is not suitable for UI generation. That's why you almost always put a a layer of logic in between to interpret the DB information to the user. Another thing is that when you generate the UI from DB you will end up displaying the inner workings of the system, something that you normally don't want to do.
But it depends on where the DB came from. If it was created to exactly reflect what the users goals of the system is. If the users mental model of what the application should help them with is stored in the DB. Then it might just work. But then you have to start at the users end. If not I suggest you don't go that way.
您能从应用架构的角度来看待您的问题吗？ 我将您视为另一个数据库恐怖分子 - 试图通过编写存储过程来解决所有问题。 为什么要有 UI？ 尝试在数据库脚本中执行此操作。 采用这种方法后，您最终会使用哪种复合系统？ 当系统服务于不同的业务时——尝试模块化、有选择地发现组件、限制共享引用。 UI应可替换，独立于业务层。 当在数据库中存储如此多的数据时——存在 UI 的硬依赖性——系统变得庞大。 在生成UI的场景中如何实现MVVM模式？ 像 Blend 这样的设计器包含许多功能，这些功能无法被大多数未来派 UI 生成器所取代 - 除非 - 您的开发平台只是记事本。
Can you look on your problem from application architecture perspective? I see you as another database terrorist – trying to solve all by writing stored procedures. Why having UI at all? Try do it in DB script. In effect of such approach – on what composite system you will end up? When system serves different businesses – try modularization, selectively discovered components, restrict sharing references. UI shall be replaceable, independent from business layer. When storing so much data in DB – there is hard dependency of UI – system becomes monolith. How you implement MVVM pattern in scenario when UI is generated? Designers like Blend are containing lots of features, which cannot be replaced by most futuristic UI generator – unless – your development platform is Notepad only.
有一种混合方法，其中表单和所有内容都在数据库中描述，以确保服务器端的一致性，然后对其进行编译以确保客户端部署时的效率。
一个现实的例子是企业软件 MS Dynamics AX。
它有一个“数据”数据库和一个“模型”数据库。
“模型” 存储表单、类、作业以及应用程序运行所需的每个工件。
部署新的软件结构过去是转储模型数据库并启动CIL编译（CIL是通用中间语言，微软在.net中使用的东西）
这种方式适合企业级软件，可以处理大型定制。 但请记住，这种方法设置了一个框架，以后维护和自定义应用程序的任何人都应该很好地理解该框架。
There is a hybrid approach where forms and all are described in a database to ensure consistency server side, which is then compiled to ensure efficiency client side on deploy.
A real-life example is the enterprise software MS Dynamics AX.
It has a 'Data' database and a 'Model' database.
The 'Model' stores forms, classes, jobs and every artefact the application needs to run.
Deploying the new software structure used to be to dump the model database and initiate a CIL compile (CIL for common intermediate language, something used by Microsoft in .net)
This way is suitable for enterprise-wide software and can handle large customizations. But keep in mind that this approach sets a framework that should be well understood by whoever gonna maintain and customize the application later.
我这样做（在 PHP / MySQL 中）是为了自动生成我为客户端构建的 CMS 的部分。 它工作正常，我的主要问题是生成表单的代码变得非常不透明且难以理解，因此难以重用和修改，所以我没有重用它。
请注意，这些表遵循严格的约定（例如命名等），这使得 UI 可以预期特定的列并推断有关列和表的命名的信息。 需要元信息来帮助 UI 显示数据。
一般来说，它可以工作，但问题是，如果您的 UI 只是镜像数据库，那么可能还有很大的改进空间。 一个好的 UI 应该不仅仅是镜像数据库，它应该围绕人类交互模式和偏好构建，而不是围绕数据库结构构建。
所以基本上，如果你想要便宜并做一个快速而肮脏的界面来镜像你的数据库，那么就去做吧。 主要的挑战是找到可以做到这一点的高质量代码或自己编写。
I did this (in PHP / MySQL) to automatically generate sections of a CMS that I was building for a client. It worked OK my main problem was that the code that generates the forms became very opaque and difficult to understand therefore difficult to reuse and modify so I did not reuse it.
Note that the tables followed strict conventions such as naming, etc. which made it possible for the UI to expect particular columns and infer information about the naming of the columns and tables. There is a need for meta information to help the UI display the data.
Generally it can work however the thing is if your UI just mirrors the database then maybe there is lots of room to improve. A good UI should do much more than mirror a database, it should be built around human interaction patterns and preferences, not around the database structure.
So basically if you want to be cheap and do a quick-and-dirty interface which mirrors your DB then go for it. The main challenge would be to find good quality code that can do this or write it yourself.
从我的角度来看，当表结构需要进行非常简单的更改时，更改编辑表单始终是一个问题。
我总有一种感觉，我们必须花太多时间重写 CRUD 表单，而不是开发有用的东西，比如处理/报告/分析数据、为决策提供警报等......
出于这个原因，我很久以前就做了一个代码生成器。 因此，通过一个简单的限制重新生成表单变得更加容易：保留 CSS 类名称。 简直就是这样！
UI 始终基于非常“标准”的代码，由自定义 CSS 控制。
每当我需要更改数据库结构，因此更新编辑表单时，我都必须重新生成代码并重新部署。
我注意到的一个缺点是对先前生成的代码所做的更改（自定义、改进等），当您重新生成它时，这些更改会丢失。
但无论如何，由代码生成器完成大量工作的优势是巨大的！
我最初是为 2000 年代的 Microsoft ASP（Active Server Pages）和 Microsoft ASP（Active Server Pages）做的。 Microsoft SQL Server...因此，当该技术被 .NET 取代时，我的代码生成器就变得过时了。
我为 PHP 做了类似的东西，但我从未完成它...
无论如何，通过小实验，我发现动态生成代码可能会更有帮助（并且这种方法不排除已保存的生成代码）：不用担心更改数据库ETC。
因此，下一步是创建一些我非常自豪地在这里展示的东西，我认为这是解决本线程中提出的问题的一个很好的解决方案。
我将从适用的用例开始： https://data-seed.tech/usecases.php。
我努力添加有关如何使用的详细信息，但如果仍然缺少某些内容，请在这里告诉我！
您可以更改数据库结构，并且无需任何代码即可开始编辑数据，更重要的是，您可以使用用于 CRUD 操作的 API。
我仍然是“代码生成器”方法的粉丝，我认为这只是我用于 DATA-SEED 的 XML/XSLT 的一种风格。 我计划添加代码生成器功能。
From my perspective, it was always a problem to change edit forms when a very simple change was needed in a table structure.
I always had the feeling we have to spend too much time on rewriting the CRUD forms instead of developing the useful stuff, like processing / reporting / analyzing data, giving alerts for decisions etc...
For this reason, I made long time ago a code generator. So, it become easier to re-generate the forms with a simple restriction: to keep the CSS classes names. Simply like this!
UI was always based on a very "standard" code, controlled by a custom CSS.
Whenever I needed to change database structure, so update an edit form, I had to re-generate the code and redeploy.
One disadvantage I noticed was about the changes (customizations, improvements etc.) done on the previous generated code, which are lost when you re-generate it.
But anyway, the advantage of having a lot of work done by the code-generator was great!
I initially did it for the 2000s Microsoft ASP (Active Server Pages) & Microsoft SQL Server... so, when that technology was replaced by .NET, my code-generator become obsoleted.
I made something similar for PHP but I never finished it...
Anyway, from small experiments I found that generating code ON THE FLY can be way more helpful (and this approach does not exclude the SAVED generated code): no worries about changing database etc.
So, the next step was to create something that I am very proud to show here, and I think it is one nice resolution for the issue raised in this thread.
I would start with applicable use cases: https://data-seed.tech/usecases.php.
I worked to add details on how to use, but if something is still missing please let me know here!
You can change database structure, and with no line of code you can start edit data, and more like this, you have available an API for CRUD operations.
I am still a fan of the "code-generator" approach, and I think it is just a flavor of using XML/XSLT that I used for DATA-SEED. I plan to add code-generator functionalities.