当前位置:  开发笔记 > 编程语言 > 正文

裸体对象模式(和UI自动生成)的未来

如何解决《裸体对象模式(和UI自动生成)的未来》经验,为你挑选了2个好方法。

我问的是模式,而不是框架.这是关于UI自动生成问题的后续行动.

    您是否相信元数据中UI自动生成的概念?

    这种方式可以解决哪些问题?

当我创建一个小型库以支持我的学生项目时,问题出现了,该项目基于对象的元数据在运行时生成交互式CLI.我认为它产生的CLI非常不错.

另一个极端是裸体对象框架,这是相当普遍的,但它产生的UI是可怕的,IMO.

很明显,每个问题都是特定的,需要特定的用户界面,但也许有几类问题可以接受自动生成?



1> Michael Borg..:

是的,我相信基于元数据的自动生成应用程序的概念非常合理 - 主要是因为它通过减少大多数应用程序中的大量冗余来减少开发时间并提高代码质量,其中每个域数据字段都在数据库中表示,在模型中,在UI中,并且通常还在各种映射层中多次.

我认为未来是自动生成的应用程序,可以在必要时进行修改.目前,这是AFAIK真的不可能; 例如,Rails只允许您在使用静态脚手架时完全自定义UI,这基本上意味着代码生成,即域模型中的许多进一步更改不会自动在UI中表示,因为生成代码时发生了重复.

我相信第一个能够将完整的自动生成与完全可修改性结合起来的框架将成为以前未知程度的事实上的开发标准.虽然我们很可能会以小步骤到达那里,以便不会有这样一个统治框架.



2> Stephan Egge..:

看看JMatter,这是一个相当好看的Naked Objects实现.

http://www.jmatter.org

还有Chris Muller关于MAUI的工作,以及Lukas Renggli关于Magritte(Squeak/Smalltalk)的工作

我们在应用程序的配置部分中有很多生成的UI.所有这些列表永远存在,并由系统管理员在蓝色的月亮中更改一次.

我发现大多数具有数据库后端的应用程序往往从OO和NO角度来看设计不好,如Pawson和Matthews的NO书中所示.

推荐阅读
Gbom2402851125
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有