裸體物件。好或壞

Question

我最近被暴露在裸露的物體中。它看起來像一個相當體面的框架。然而，我並沒有像普遍使用的那樣看到Spring，Spring。那麼爲什麼這個框架沒有獲得任何主流應用程序的功勞你看到它有什麼缺點？

Answer 1

從我的經驗用NOF 3.0.3應用開發商正視開發成功應用的負擔...

好：

• 自動地生成UI的DnD爲您的域對象，如確實爲持久性什麼的db4o。根據MVC模式創建者，這就是MVC總是意味着什麼的。
• 該框架只會要求您的域對象（PO​​JO）從AbstractDomainObject子類化，即所有最小布線。
• 該框架支持約定OVER配置：許多註釋不會令人擔憂的XML配置文件。
• 適用於原型設計以及db4o，以實現持久性。
• 開箱即用的Hibernate功能。
• 就我而言，我需要從下載到Hello World應用程序30分鐘。 （IntelliJ IDEA IDE）
• 部署爲JNLP，獨立Web（NOX​​嵌入Jetty或Scimpi風味）和Eclipse RCP。
• 當您在論壇尋求幫助時，NOF團隊隨時爲您服務。
• 裸體對象模式是一個很棒的想法，幫你一個忙，花點時間來討好它。
• Theres很多實用性的火焰周圍的拖放界面怎麼回事，但如果你未來的最終用戶只需無法與免打擾用戶界面的工作，那麼你是大麻煩呢。

壞：

• 沒有，我能想到的。

還挺難看：

• 沒有允許Swing組件，所以告別了JGoodies和所有您最喜愛的Swing組件集。 UI組件是定製的;讓你知道他們看起來像90年代早期的VB控制。但工程中有一個SWT端口。
• 長字符串的多行字段有一些問題。 （NOF 3.0.3）
• 圖像的DnD UI是有點兒車。
• getters n setters的驗證代碼僅在從UI中修改了域對象時纔會觸發。 （這可能是錯誤的，因爲我的nbbness，讓我們希望NOF提交者糾正我）

• 如果一個對象是從一個非ui線程修改，讓我們說一個b.g.工人，這樣的對象將不會在屏幕上更新它的視圖
  。這會使DnD自動生成的用戶界面上的用例（如實時表示郵件隊列）無效。 （再次）

• 韋科

Answer 2

它已成功使用here in Ireland。

我想原因它未得到較爲流行的有：

• 你需要很多的工具包信心，你正在使用
• 它使GUI的危險因素，而不是一個沒有腦子（無論在技術上還是在可用性測試）
• 它並不適用於網絡（據我所知），這是大多數的重點是目前...

Answer 3

加雷思使一些優秀點。

還有其他問題，例如很難控制外觀和感覺，而且它們對習慣於窗口模型的人而言是違反直覺的。還有一些建模問題，因爲並非所有的應用程序領域都適合指導主題表示。

「小公民程序員」的普遍模式在smalltalk和裸體對象社區中也有承擔，這也成爲一個值得懷疑的想法。大多數用戶似乎並不十分擔心自己改變功能，所以在對象中思考並不是那麼有用。

Answer 4

去年我玩過它，並得出結論認爲這很容易合作。

您可以根據您的數據模型免費獲得GUI的Naked Objectsis的優勢。缺點是典型的用戶不會將他的過程視爲一個記錄集合。

我的結論是，裸體對象對於概念上處理記錄的內部應用程序來說非常棒，例如庫存應用程序或賬單處理應用程序。

如果你需要任何不同的東西來適應你的願望，可能比使用爲支持你想要的應用程序而編寫的框架更多的工作。

順便說一句，有一個Web渲染選項;請參閱演示Naked Objects Demo。

Answer 5

可能它沒有得到更多關注的原因是J2EE世界已經習慣於在如此多的層上堆砌到應用程序上，裸露的對象顯得太天真了。

我們的服務在哪裏？你的意思是說，任何裸露的對象都能立即訪問數據庫？如果我們需要用RMI調用來公開應用程序呢？

加有沒有那麼多市場，因爲它將不是框架的開發人員:)

Answer 6

我剛剛看到了這一點。幾個小的更正，否則大多數評論是非常公平的。

1）'該框架只會要求您的域對象（PO​​JO）從AbstractDomainObject進行子類化，即所有最小布線。'

裸體對象不需要將域對象從AbstractDomainObject中分類，儘管這通常是最方便的事情。

如果你不想繼承，你需要做的就是提供一個IDomainObjectContainer類型的屬性，然後框架在創建或檢索對象時將注入一個容器。該容器具有用於Resolve（），ObjectChanged（）和NewTransientInstance（）的方法，這是與您必須使用的框架的三個最低限度聯繫點，以便框架與您的域對象保持同步。

2）'非常適合用於原型製作以及db4o的持久性'。我們非常熱衷於使用db4o的想法，但我不知道任何使Naked Objects和db4o一起玩的人。如果有人這樣做了，我想多瞭解一下。 3）'在smalltalk和裸體對象社區中推崇的citzen程序員的一般模型......'。我們從未贊成這個想法，我不同意。裸體對象不是鼓勵用戶編程。我堅信專業開發人員的角色 - 裸體對象只是幫助他們編寫更好的軟件並提高生產力。

理查德

Answer 7

• 廣泛使用的技術有技術質量沒有很強的相關性。
• 裸體對象系統很難與類型對象組合使用： 如果我銷售的是不同類型的產品，並且需要不同產品的不同數據，則很難限制產品類型的數據。
• 他們切換許可證時不會失去動力。 （到GPL + Commercial，不是最近搬到Apache）

你看看jmatter嗎？

而另一個：如果你可以交付，這對非程序員來說很明顯。 Spring在技術領域非常重要，NO意味着開發人員必須與用戶交流。大型組織不這樣做。

Answer 8

我猜裸體對象肯定有它的相關性，而且開發人員社區重新考慮真正爲他們付出的東西的時間已經過去了：業務。相反，我們大多花時間在基礎設施，協議和所有技術廢話上。我已經看到了這樣的錯過構建的應用程序，我甚至做了一些跟隨主流的自己，告訴你分層系統總是一件好事。最糟糕的是，如果你問一些開發人員他們工作的公司是做什麼樣的業務的，那麼至少有一些人在公司工作了多年，卻沒有更深入地瞭解業務。 然而，我不認爲NakedObject會吸引絕大多數開發人員（即使是受DomainDriven開發啓發的人），因爲人們喜歡構建UI並將他們從他們身邊帶走，將他們的工作指向業務需求，不是他們想要的：我們都是VB混蛋。

Answer 9

裸體物體（NO）適用於快速原型製作。您可以專注於域模型，而不關注GUI，數據庫和解決方案的其他部分。對於生產來說，它需要NakedObjects框架本身的很多改進（bug修復，數據映射，gui等）。

因此，如果您需要爲您的解決方案獲得某種「概念驗證」，則可以使用NO。但是生產要準備投入資源開發NO框架。

順便說一句，最近我們正在努力創建基於GWT 4.0的DnD查看器。

Answer 10

我一直在研究赤裸裸的對象方法已經有一年多的時間了，我甚至沒有開始抓住它爲系統架構提供的可能性的表面。爲了恰當地利用它，它需要你創建一個範式轉換並尋求完整的面向對象解決方案，並恢復採用功能鴨式磁帶，因爲這種範式似乎只在你創建一個可以實現高層次開發的設計時才起作用。儘管如此，我非常喜歡Django在它的Django模型中實現裸物體的方式。我最喜歡的框架大部分是，我相信，它的模型的直接結果，並有一些令人驚歎的頂部我想分享有關架構：

模型字段，即映射到表列，是行爲完整的對象 - 他們知道它們在應用程序和數據庫域中的表現方式，它們如何在二者之間進行轉換，以及如何驗證它們所持有的信息並以視覺形式向用戶顯示輸入內容。所有這些都可以在模型中使用一行代碼。 哇！

經理被附加到模型並提供CRUD和集合的任何通用操作，比如可重複使用的查詢（給我最近的五篇博文，最常見的標籤等），批量刪除\更新操作和業務邏輯在實例上。 哇！

現在考慮你有一個代表用戶的模型。有時，您只想對用戶模型的所有信息進行局部視圖（重置用戶密碼時，您可能只需要用戶的電子郵件和他的祕密問題）。他們提供了一個Forms API，可以精確顯示和管理模型數據的一部分輸入。允許對處理用戶輸入的內容進行任何定製。 哇！

最終的結果是，您的模型僅用於描述用於描述特定域的信息;經理對模型執行所有操作;表單用於創建視圖和處理用戶輸入;控制器（視圖）僅用於處理HTTP動詞，如果它們與模型一起使用，則完全通過管理者和表單來進行;視圖（模板）用於演示文稿（不能自動生成的部分）。這是一個非常乾淨的建築。不同的管理者可以在不同的模型中使用和重複使用，可以爲模型創建不同的形式，不同的視圖可以使用不同的管理者。這些分離程度使您可以快速設計您的應用程序。

您創建了一個智能對象的生態系統，並從它們相互連接的方式獲取整個應用程序。前提是它們鬆散耦合（很多可能讓它們以不同方式進行通信），並且可以很容易地進行修改和擴展（針對該特定要求的幾行），遵循範例，您確實獲得了一個架構，組件編寫一次，然後在整個其他項目中重用它。這正是MVC應該始終如一，但我經常不得不從頭開始寫一些東西，即使我在幾個項目之前做了同樣的事情。