java - 裸のオブジェクト。良いまたは悪い

Question

私は最近、裸の物体にさらされています。かなりまともなフレームワークのように見えます。ただし、たとえばSpringのように広く使用されているとは思いません。では、なぜこのフレームワークは主流のアプリケーションの信用を得られないのでしょうか? あなたが見るように、その欠点は何ですか？

score 10 · Accepted Answer

NOF3.0.3を使用した私の経験から...

いいもの：

db4oが永続性のために行うように、ドメインオブジェクトのDnDUIを自動的に生成します。
MVCパターンの作成者によると、これはMVCが常に意図されていたものです。
フレームワークは、ドメインオブジェクト（POJO）に、最小限の配線であるAbstractDomainObjectからサブクラス化するように要求するだけです。
フレームワークは、設定より規約を優先します。多くのアノテーションは、おかしなXML構成ではありません。
永続性のためのdb4oと一緒にプロトタイピングに最適です。
Hibernateのすぐに使用できる機能。
私の場合、Download toHelloworldアプリから30分ほどかかりました。（IntelliJ IDEA IDE）
JNLP、スタンドアロン、Web（NOX組み込みJettyまたはScimpiフレーバー）およびEclipseRCPとしてのデプロイメント。
フォーラムで助けを求めるときは、NOFチームが常にあなたのためにいます。
ネイキッドオブジェクトパターンは素晴らしいアイデアです。自分に有利に働き、時間をかけてそれを手に入れましょう。
ドラッグアンドドロップGUIの周りでは多くのユーザビリティの炎が起こっていますが、将来のエンドユーザーが単に DnD UIを操作できない場合は、とにかく深刻な問題に直面しています。

悪い人：

私が考えることができるものはありません。

ちょっと醜い：

Swingコンポーネントは許可されていないので、JGoodiesとすべてのお気に入りのSwingコンポーネントセットに別れを告げてください。UIコンポーネントはカスタムメイドです。90年代初頭のVBコントロールのように見えることを理解するために。しかし、作業中にSWTポートがあります。
長い文字列の複数行フィールドには、いくつかの問題があります。（NOF 3.0.3）
画像のDnDUIはちょっとバグがあります。
getters n settersの検証コードは、ドメインオブジェクトがUIから変更された場合にのみ起動します。（これは私のn00bnessのためにおそらく間違っています、NOFコミッターが私を修正することを願っています）
オブジェクトが非UIスレッド、たとえばbgワーカーから変更された場合、そのようなオブジェクトは
画面上のビューを更新しません。これにより、DnD自動生成UIでメールキューをリアルタイムで表すなどのユースケースが無効になります。（また）
ヴェイッコ

score 10 · Accepted Answer

私はネイキッドオブジェクトアプローチに 1 年以上取り組んできましたが、システムのアーキテクチャにネイキッドオブジェクトが提供する可能性の表面をなぞり始めていません。ただし、それを適切に利用するには、パラダイムシフトを作成し、完全な OO ソリューションを探し出し、機能的なダックテープに頼るのをやめる必要があります。なぜなら、パラダイムは、高レベルの開発を可能にする設計を作成する場合にのみ機能するように思われるからです。

そうは言っても、Django が Django モデル内に裸のオブジェクトを実装する方法が大好きです。フレームワークについて私が気に入っていることのほとんどは、私が信じているように、そのモデルの直接の結果であり、アーキテクチャについて共有したいいくつかの驚きがあります。

テーブルの列にマップされるモデルフィールドは、動作的に完全なオブジェクトです。アプリケーションドメインとデータベースドメインの両方でどのように表現されるか、2 つの間でどのように変換されるか、保持する情報がどのように検証されて表示されるかを認識しています。ユーザーが視覚的に入力できるようにします。これらはすべて、モデル内の 1 行のコードで利用されます。うわー！

マネージャーはモデルに関連付けられており、再利用可能なクエリ (最新の 5 つのブログ投稿、最も頻繁に発生するタグなど)、一括削除/更新操作、インスタンスで実行されるビジネスロジックなど、コレクションに対する CRUD および一般的な操作を提供します。うわー！

ここで、ユーザーを表すモデルがあるとします。場合によっては、ユーザーモデルが保持するすべての情報の一部のみを表示したい場合があります (ユーザーのパスワードをリセットするときに、ユーザーの電子メールと秘密の質問だけが必要な場合があります)。彼らは、モデルデータの一部のみの入力を正確に表示および管理する Forms API を提供しました。ユーザー入力の処理方法をカスタマイズできます。うわー！

最終的に、モデルは、特定のドメインを説明するために使用する情報を説明するためにのみ使用されます。マネージャーはモデルに対してすべての操作を実行します。フォームは、ビューの作成とユーザー入力の処理に使用されます。コントローラー (ビュー) は、HTTP 動詞を処理するためだけにあり、モデルを操作する場合は、マネージャーとフォームのみを使用します。ビュー (テンプレート) は、プレゼンテーション (自動生成できない部分) のために存在します。これは、私見ですが、非常にクリーンなアーキテクチャです。さまざまなモデルでさまざまなマネージャーを使用および再利用できます。モデル用にさまざまなフォームを作成でき、さまざまなビューでさまざまなマネージャーを使用できます。これらの分離度により、アプリケーションをすばやく設計できます。

インテリジェントオブジェクトのエコシステムを作成し、それらが相互接続されている方法からアプリケーション全体を取得します。それらが疎結合されており（さまざまな方法で通信できるようにするための多くの可能性）、簡単に変更および拡張できる（その特定の要件に対して数行）という前提で、パラダイムに従って、実際にアーキテクチャを取得しますコンポーネントは一度書き込めば、他のプロジェクト全体で再利用できます。それが MVC の本来あるべき姿ですが、数年前に同じことをしたにもかかわらず、何かを最初から書かなければならないことがよくありました。

score 7 · Accepted Answer

ここアイルランドで成功裏に使用されています。

普及しなかった理由としては、次のことが考えられます。

使用しているツールキットには多くの自信が必要です
これにより、GUI が簡単なものではなくリスク要因になります (技術的にも、ユーザビリティテストの両方においても)。
(私の知る限り) Web には適用できません。

score 5 · Accepted Answer

私はこれを見たばかりです。いくつかのマイナーな修正、それ以外の場合、ほとんどのコメントは非常に公平です.

1) 「フレームワークは、ドメインオブジェクト (POJO) を AbstractDomainObject からサブクラス化するように要求するだけで、これがすべての最小限の配線です。」

Naked Objects では、ドメインオブジェクトを AbstractDomainObject からサブクラス化する必要はありませんが、これが通常最も便利なことです。

継承したくない場合は、IDomainObjectContainer 型のプロパティを指定するだけで、オブジェクトが作成または取得されるときに、フレームワークによってオブジェクトにコンテナーが挿入されます。コンテナには Resolve()、ObjectChanged()、NewTransientInstance() のメソッドがあります。これらは、使用する必要があるフレームワークとの 3 つの最小限の接点であるため、フレームワークはドメインオブジェクトと同期したままになります。

2) 「永続化のための db4o と一緒にプロトタイプを作成するのに最適です」。私たちは db4o と連携するというアイデアに非常に熱心ですが、Naked Objects と db4o を一緒にプレイさせた人を私は知りません。誰かがこれを行った場合、私はそれについてもっと聞きたいです。

3) 「スモールトークやネイキッドオブジェクトコミュニティで支持されている市民プログラマーの一般的なモデル ...」。私たちはその考えを支持したことはありませんし、私はそれに同意しません。Naked Objects は、ユーザーにプログラミングを勧めるものではありません。私はプロの開発者の役割を固く信じています.Naked Objectsは、彼らがより良いソフトウェアをより生産的に書くのを助けるだけです.

リチャード

score 4 · Accepted Answer

昨年かそこらで遊んでみましたが、非常に扱いやすいと結論付けました。

Naked Objects の強みは、データモデルに従って構造化された GUI を無料で入手できることです。不利な点は、一般的なユーザーが自分のプロセスをレコードのコレクションとして考えていないことです。

私の結論は、Naked Objects は、在庫アプリケーションや請求書処理アプリケーションのように、記録を概念的に扱う内部アプリケーションに非常に適しているということです。

何か別のことが必要な場合、フレームワークを希望に合わせて調整することは、必要な種類のアプリケーションをサポートするために作成されたフレームワークを使用するよりもはるかに多くの作業になる可能性があります。

ところで、Web レンダリングオプションがあります。Naked Objects Demoでデモを参照してください。

score 2 · Accepted Answer

NakedObjects（NO）は、ラピッドプロトタイピングに適しています。GUI、DB、およびソリューションの他の部分に注意を払わなくても、ドメインモデルに集中できます。本番環境では、NakedObjectsフレームワーク自体に多くの改善（バグ修正、データマッピング、GUIなど）が必要です。

したがって、ソリューションに対して何らかの「概念実証」を取得する必要がある場合は、NOを使用できます。しかし、本番環境では、NOフレームワークの開発にリソースを投資する準備ができています。

ところで、最近、NO4.0のGWTに基づいたDnDビューアの作成に取り組んでいます。

score 2 · Accepted Answer

おそらく、これ以上注目されていない理由は、J2EEの世界がアプリケーションに非常に多くのレイヤーを積み上げることに慣れており、裸のオブジェクトが素朴なものとして出くわしているためです。

私たちのサービスはどこにありますか？裸のオブジェクトがあれば、データベースにすぐにアクセスできるということですか？RMI呼び出しでアプリケーションを公開する必要がある場合はどうなりますか？

さらに、成功するアプリケーションを開発する負担がフレームワーク開発者ではなくアプリケーション開発者に直接かかるため、市場に出すものはそれほど多くありません:)

score 2 · Accepted Answer

NakedObject には間違いなく関連性があり、開発者コミュニティが実際に支払っているもの、つまりビジネスに再び焦点を当てるのに十分な時間があると思います。代わりに、私たちはほとんどの時間をインフラストラクチャ、プロトコル、およびそれらすべての技術的ながらくたに費やしています. 私はそのような構築されていないアプリケーションを見てきましたし、システムを階層化することは常に良いことであることを教えながら、私自身も主流に従っていくつかのことを行いました。最悪なのは、何人かの開発者に、彼らが働いている会社がどのようなビジネスを行っているかを尋ねると、その会社で何年も働いているにもかかわらず、そのビジネスについて深く理解していない人が少なくとも何人かいるということです。でも、

score 2 · Accepted Answer

ガレスはいくつかの優れた点を挙げています。

ルックアンドフィールを制御するのが難しく、ウィンドウモデルに慣れている人にとっては直感に反するという事実など、他にも問題があります。また、すべてのアプリケーションドメインが直接的なオブジェクト表現に適しているわけではないという点で、モデリングの問題もあります。

smalltalk コミュニティやネイキッドオブジェクトコミュニティで支持されている「市民プログラマー」の一般的なモデルも、疑わしい考えとして出てきます。ほとんどのユーザーは、機能自体を変更することにそれほど悩まされていないようです。そのため、オブジェクトで考えることはあまり役に立ちません。

score 0 · Accepted Answer

テクノロジーの普及とテクノロジーの質との強い相関関係はありません。
NakedObject システムは、タイプオブジェクトと組み合わせて使用するのは困難です。さまざまな種類の製品を販売していて、製品ごとに異なるデータが必要な場合、製品タイプのデータを制約することは困難です。
ライセンスを切り替えたとき、NO は勢いを失いました。(最近の Apache への移行ではなく、GPL+Commercial へ)

jmatterを見てみましたか？

[編集] そしてもう 1 つ: 配信できるかどうかが非プログラマーに明らかになります。Spring は非常に技術的な領域にあり、NO は開発者がユーザーと話をしなければならないことを意味します。大規模な組織はそれをしません。

java - 裸のオブジェクト。良いまたは悪い

10 に答える 10

Related

Reference