15

フレームワークではなく、パターンについて質問します。これは、 UI 自動生成に関する質問へのフォローアップのようなものです。

  1. メタデータからの UI 自動生成の概念を信じますか?

  2. この方法でどのような問題にアプローチできますか?

オブジェクトのメタデータに基づいて実行時にインタラクティブな CLI を生成する学生プロジェクトをサポートする小さなライブラリを作成したときに、この疑問が生じました。そして、それが生成するCLIはかなりまともだと思います。

対極にあるのはNaked Objects Frameworkです。これはかなり普遍的ですが、それが生成する UI は恐ろしいものです。

明らかに、すべての問題は特定のものであり、特定の UI が必要ですが、自動生成が受け入れられる問題のクラスがいくつかあるのではないでしょうか?

4

7 に答える 7

15

はい、メタデータ ベースの自動生成アプリケーションの概念は非常に健全だと思います。主な理由は、各ドメイン データ フィールドがデータベースで表されるほとんどのアプリケーションで発生する膨大な冗長性を削減することで、開発時間を大幅に短縮し、コードの品質を向上させるためです。モデル、UI、そして多くの場合、さまざまなマッピング レイヤーで数回。

将来は、必要に応じて変更できる自動生成アプリだと思います。現在、これは実際には不可能です。たとえば、Rails では、静的な足場を使用する場合にのみ UI を完全にカスタマイズできます。これは基本的にコード生成を意味します。つまり、ドメイン モデルのさらなる多くの変更は、コードが生成されたときに重複が発生したため、UI に自動的に表示されません。 .

完全な自動生成とその後の完全な変更可能性をうまく組み合わせた最初のフレームワークは、これまで知られていなかった事実上の開発標準になると私は信じています。ただし、このような単一の支配的なフレームワークが存在しないように、小さなステップでそこに到達する可能性が最も高いです。

于 2009-01-18T11:14:04.960 に答える
6

裸のオブジェクトのかなり見栄えの良い実装である JMatter を見てください。

http://www.jmatter.org

また、MAUI に関する Chris Muller の作業と、Magritte に関する Lukas Renggli の作業 (どちらも Squeak /Smalltalk) もあります。

アプリの構成部分には、多くの生成された UI があります。永遠に存在し、システム管理者によってブルームーンで一度変更されたすべてのリスト。

Pawson と Matthews による NO の本で既に示されているように、データベース バックエンドを備えたほとんどのアプリケーションは、OO と NO の観点から見ると設計が悪い傾向があることがわかりました。

于 2009-01-18T11:52:17.690 に答える
4

Re: qn #1 ... メタデータからの UI 自動生成の概念を信じますか? ... Naked Objects (Java) フレームワークのコミッターの 1 人であり、DDD + NO に関する本を書いている私は、あなたの最初の質問に間違いなく「はい」と答えるつもりです。

質問はメタデータに言及しています。これがNOが成功するための鍵だと思います。最新バージョン (2 月にベータ版になる予定) では、メタモデルが開かれており、非常に拡張性が高いため、独自のプログラミング規則/注釈に従ってドメイン モデルを記述できます。独自のメタデータを探して、より洗練されたビューを提供できます。(たとえば、オブジェクトが Location インターフェイスを実装している場合、Google マップに表示されるとします)。

qn #2 について ... この方法でアプローチできる問題の種類 ... 「主権アプリケーション」 (組織内で使用されるトランザクション、運用システム) には「一時的なアプリケーション」よりも NO の方が適していると常に言ってきました。 」 (空港のキオスクのように)。NO GUI では、ユーザーがドメインに精通している必要があります。そうでない場合、ユーザーは何を見ているのかわかりません。

もちろん、まだ欠けているのは洗練された視聴者です。NO GUI についてはあなたの言うとおりです。忠実度が低いことは間違いありません (ただし、.NET バージョンは大幅に改善されています。最近の infoq.com の記事を参照してください)。Java 側では、scipi.org という姉妹プロジェクトがあり、多くの可能性があります...基本的な Web GUI を無料で提供しますが、必要に応じて段階的に Web ページを手作りできます。同様に動作する Eclipse RCP GUI にも取り組んでいます。

これに追加するもう1つのことは、カスタムGUIおよび/またはプレゼンテーションレイヤーを作成することを選択した場合でも、NOアプローチには価値があるということです(私は信じています)。つまり、非常に堅牢な pojo ドメイン層を構築するための設計ツールとして使用し、それを自由にスキン化することができます。問題は、NO が最初にそのような条件で販売されたことがないことです。そのため、ほとんどの場合、NO パターンはオール オア ナッシングの問題と見なされます。

ダン

于 2009-01-19T23:17:13.370 に答える
3

これを調べる 1 つの方法は、Toad や MySQL Browser などから得られるユーザー インターフェイス (ユーザー インターフェイスがテーブルと関連するメタデータから直接構築される) と、熟練したデザイナーが使用するユーザー インターフェイスとの違いを検討することです。実際のアプリケーション用に開発します。あまり似ていない場合、自動生成フレームワークにとってはかなり簡単に達成できるはずです。

あなたが言うように、この種の自動生成で非常にうまく機能する問題のクラスと、そうでない問題のクラスがあります。私の考えでは、重要なことは、ユーザー インターフェイスで公開している実装モデル (またはその一部) が、ユーザーの概念モデルにどれだけうまく対応しているかということです。第 2 に、限られた一連のユーザー インターフェイス コンポーネント (これが汎用の UI 生成フレームワークであると仮定して) を介して、アプリケーションの動作をどの程度うまく表現できるかです。

この記事「ユーザー インターフェイスのユニバーサル モデル」は興味深いかもしれません。

于 2009-01-18T10:51:17.407 に答える
2

I think the idea of automatically generated UIs has a lot of potential especially for your average form-and-table layout database user interface. However, even there a human needs to be in the loop, having the ability to override the output without it being overwritten with the next regeneration.

I suspect automatically generated UIs would be more successful today if interaction designers were more involved in developing the generation algorithms. My impression is that historically the creators of these systems don’t know what kinds of UI-related metadata to include or how to use it. Specifying labels, value ranges, formats, and orders for fields is a start, but more high level information is needed. Sufficient modeling of the tasks and user roles in particular tends to be lacking, along with some basic style-guide-level principles for UI.

Oracle’s Designer 2000, for example, was on the right track in including not only the entities and relations in the model, but also the tasks in the form of a functional hierarchy. Then they blew it by misapplying this metadata (e.g., assuming that depth is always preferred to breadth) and including fundamental flaws when generating the UI (e.g., only one primary window can be opened at a time). The result was IUs that were not even consistent with Oracle’s own Applications User Interface Standards.

于 2009-01-18T16:46:12.117 に答える
2

顧客がシステムを試してテストデータを作成できるようにする基本的なUIをすばやく立ち上げることは、価値のあることです。Naked Objectsフレームワークは、出荷前に「手作り」のUIに置き換える必要がある場合でも、「<strong>ブートストラップ」に役立ちます。

私が取り組んできたほとんどのシステムでは、簡単なハウスキーピングテーブルがたくさんありました。これらのすべてのテーブルには、それらを編集および表示するためのUIなどが必要です。これらの単純なエディターには一貫性があることにも大きな価値があります。ここでは、メインの「日常」のUIが「手作り」である場合でも、裸のオブジェクトフレームワークによって多くの時間を節約できます。</ p>

于 2010-06-22T08:39:04.740 に答える
2

「ネイキッド オブジェクト」アプローチ (フレームワークではなく、AFAIK) を使用したいくつかの失敗したプロジェクト (代替の設計を支援するためにかなり高価なコンサルタントとして連れてこられたケース) を見てきました。 1 つのプロジェクトで多くの UI を置き換えましたが、元の化身では同様のアプローチがありました (アプリケーション全体は、コンテキスト メニューとプロパティ シートを介してアクセスされるオブジェクトのツリーでした。これは 1998 年頃の NetBeans 2.0 でした。IDE は巨大な階層 JavaBean です)。 )。

肝心なのは、ユーザーはアーキテクチャを気にするのではなく、あなたが思いつくことができる最も理解しやすい、単なる人間にとって最も理解しやすい相互作用のセットで自分がする必要があることを成し遂げることを気にかけているということです。それがたまたまアーキテクチャと一致する場合は、幸運な日を過ごしていますが、それは本当に偶然です。ユーザーにあなたのアーキテクチャを気にかけようとする (または知ってさえもらおうとする) ことは、誰も使いたくないソフトウェアのレシピです

コードは通常、常に互換性があるわけではない 2 つの目標に基づいて設計する必要があります。

  1. 保守性 - コードを書いていない人でもコードを理解できる
  2. 安定性とパフォーマンス - つまり、コードがコンピューターに物理的に実行を要求するアクティビティの両方が可能であり、妥当な時間枠内で完了することができます

これら 2 つの目標を達成するために作成するのが理にかなっている抽象化とコード構造が、あらゆる種類のユーザー インターフェイス要素に正確にマッピングされることはほとんどありません。聴衆が技術的な人であれば、ギリギリで済むこともあります。しかし、それでも、プログラマーとマシンにとって理にかなっているアーキテクチャーの上に少なくとも「プレゼンテーション層」アダプター層があれば、より多くのユーザーを喜ばせる可能性があります。

于 2010-08-30T23:53:02.057 に答える