Голые объекты. Хорошо или плохо

Ответ 1

Из моего опыта использования NOF 3.0.3...

Хорошее:

• Автоматически генерирует пользовательский интерфейс DnD для ваших объектов домена, например, что делает db4o для сохранения.
• Это то, что всегда было MVC, согласно создателю шаблона MVC.
• Фреймворк только запрашивает, чтобы ваши объекты домена (POJO) были подклассифицированы из AbstractDomainObject, что соответствует минимальной проводке.
• Рамка поддерживает стандартную конфигурацию конференц-связи: множество аннотаций не содержит шаблонов XML-конфигурации.
• Отлично работает для прототипирования вместе с db4o для настойчивости.
• Функциональные возможности для спящего режима.
• В моем случае мне потребовалось 30 минут от приложения "Загрузить в Hello". (IntelliJ IDEA IDE)
• Развертывание как JNLP, автономный, Web (NOX embedded Jetty или Scimpi) и Eclipse RCP.
• Команда NOF ВСЕГДА там, когда вы просите о помощи на форумах.
• The Naked Object Pattern - это потрясающая идея, сделай себе одолжение и не торопитесь с ней.
• Theres много гибкости в использовании, используемой в графическом интерфейсе Drag and Drop, но если ваши потенциальные конечные пользователи просто не могут работать с интерфейсом DnD, то вы все равно вдалеке.

Плохо:

• Ничего, о чем я могу думать.

Какое-то уродливое:

• Никакие компоненты Swing не разрешены, поэтому попрощайтесь с JGoodies и всеми вашими любимыми компонентами Swing. Компоненты пользовательского интерфейса выполнены на заказ; чтобы вы поняли, что они выглядят как ранние 90 элементов управления VB. Но в работе есть SWT-порт.
• Многострочное поле для длинных строк имеет некоторые проблемы. (NOF 3.0.3)
• Пользовательский интерфейс DnD для изображений выглядит бесполезно.
• Код проверки для getters n seters только срабатывает, если объект домена изменен из пользовательского интерфейса. (Вероятно, это неправильно из-за моего n00bness, позволяет надеяться, что корректор NOF исправляет меня).

• Если объект изменен из потока, отличного от ui, скажем, b.g. работник, такой объект будет
  не обновлять свой вид на экране. Это делает недействительным вариант использования, например, представление очереди сообщений в реальном времени на автогенерированном пользовательском интерфейсе DnD. (Снова)

• Veikko

Ответ 2

Я работаю над подходом с голыми объектами уже более года, и я даже не начал поцарапать поверхность возможностей, которые он предоставляет для вашей системной архитектуры. Чтобы правильно использовать его, он требует, чтобы вы создали сдвиг парадигмы и искали полноценные решения OO и отказались от использования функциональных утиных лент, потому что парадигма, кажется, работает только тогда, когда вы создаете проект, который позволил бы на высоком уровне развития.

Сказав это, я абсолютно обожаю, как Django реализовал в нем свои объекты Django. Большинство вещей, которые мне нравятся в структуре, были такими, какими я верю, прямым результатом этих моделей, и есть некоторые слабые места, которые я хотел бы рассказать об архитектуре:

Поля модели, которые сопоставляются с столбцами таблицы, являются поведенчески полными объектами - они знают, как они представлены как в домене приложений, так и в базе данных, как они преобразуются между ними и как данные, которые они хранят, проверяются и визуально отображается пользователю для ввода. Все это используется с одной строкой кода в вашей модели. Wow

Теперь рассмотрим, что у вас есть модель, представляющая пользователя. Иногда вам хотелось бы только частично просмотреть всю информацию, которую использует модель пользователя (при сбросе пароля пользователя вам может понадобиться только электронная почта пользователя и его секретный вопрос). Они предоставили API форм, который точно отображает и управляет входами только для части данных модели. Позволяет выполнить любую настройку того, что/как обрабатывается пользователем. Wow

Конечный результат заключается в том, что ваши модели используются только для описания того, какую информацию вы используете для описания определенного домена; менеджеры выполняют все операции над моделями; формы используются для создания представлений и для обработки пользовательских входов; контроллеры (представления) существуют только для обработки HTTP-глаголов, и если они работают с моделями только с помощью менеджеров и форм; представления (шаблоны) для презентации (часть, которая не может быть автоматически сгенерирована). Это, imho, очень чистая архитектура. Различные менеджеры могут использоваться и повторно использоваться в разных моделях, для моделей могут быть созданы различные формы, разные представления могут использовать разные менеджеры. Эти степени разделения позволяют быстро разрабатывать ваше приложение.

Вы создаете экосистему интеллектуальных объектов и получаете целое приложение из того, как они взаимосвязаны. С предпосылкой, что они слабо связаны (много возможностей для того, чтобы позволить им общаться по-разному), и их можно легко модифицировать и расширить (несколько строк для этого конкретного требования), следуя парадигме, на которой вы действительно получаете архитектуру, где вы компонент писать один раз, а затем повторно использовать его во всех других проектах. Это то, чем должен был быть MVC, но мне часто приходилось писать что-то с нуля, хотя я сделал то же самое несколько проектов назад.

Ответ 3

Он успешно использовался здесь, в Ирландии.

Я думаю, что причины, по которым он не был более популярным, следующие:

• Вам нужна большая уверенность в инструментах, которые вы используете.
• Это делает GUI фактором риска вместо беспроблемного (как технически, так и в юзабилити-тестировании).
• Он не применим к сети (насколько я знаю), в которой большая часть фокуса присутствует как присутствующая...

Ответ 4

Я только что видел это. Несколько незначительных исправлений, в противном случае большинство комментариев очень справедливы.

1) 'Фреймворк только запрашивает, чтобы ваши объекты домена (POJO) были подклассифицированы из AbstractDomainObject, которые имеют минимальную проводку.'

Голые объекты не требуют, чтобы объекты домена были подклассифицированы из AbstractDomainObject, хотя обычно это наиболее удобно.

Если вы не хотите наследовать, все, что вам нужно сделать, это предоставить свойство типа IDomainObjectContainer, и среда затем введет контейнер в ваши объекты, когда они будут созданы или извлечены. В контейнере есть методы для Resolve(), ObjectChanged() и NewTransientInstance(), которые являются тремя минималистскими точками контакта с каркасом, которые вы должны использовать, чтобы инфраструктура оставалась в синхронизации с вашими объектами домена.

2) "Отлично работает для прототипирования вместе с db4o для настойчивости". Мы очень заинтересованы в идее работы с db4o, но я не знаю никого, кто делал Naked Objects и db4o вместе. Если кто-то это сделал, я хотел бы узнать больше об этом.

3) "Общая модель программиста цитцена, как описано в небольших сообществах и сообществах голых объектов...". Мы никогда не поддерживали эту идею, и я не согласен с ней. "Голые объекты" НЕ предназначены для поощрения пользователей к программированию. Я твердо уверен в роли профессионального разработчика - Naked Objects просто помогает им лучше писать программное обеспечение и более продуктивно.

Ричард

Ответ 5

Я играл с ним в прошлом году или около того, и пришел к выводу, что с ним очень легко работать.

Сила Naked Objectsis заключается в том, что вы получаете бесплатный графический интерфейс, структурированный в соответствии с вашей моделью данных. Недостатком является то, что типичный пользователь не думает о своих процессах как о наборе записей.

Мое заключение состояло в том, что Naked Objects действительно отлично подходит для внутреннего приложения, которое концептуально обрабатывает записи, такие как приложение инвентаризации или приложение для обработки счетов.

Если вам нужна какая-то другая адаптация рамки к вашим пожеланиям, это может быть намного больше, чем использование фреймворка, написанного для поддержки того приложения, которое вы хотите.

Кстати, есть опция веб-рендеринга; см. демонстрацию Демо-версия обнаженных объектов.

Ответ 6

Я думаю, что NakedObject определенно имеет свою актуальность и больше, чем время, когда сообщество разработчиков переориентируется на то, что действительно платит им: бизнес. Вместо этого мы в основном тратим свое время на инфраструктуру, протоколы и всю техническую дерьмо. Я видел такие пропущенные приложения, и я даже сам по себе следил за мейнстримом, обучая вас тому, что накладывать систему всегда хорошо. Хуже всего то, что если вы спросите некоторых разработчиков о том, какой бизнес компания, над которой они работают, вы найдете, по крайней мере, тех, кто много лет работал в компании, не углубляясь в понимание бизнеса. Тем не менее, я не считаю, что NakedObject привлечет огромное количество разработчиков (даже тех, кто вдохновлен DomainDrivenDevelopment) просто потому, что люди любят создавать пользовательские интерфейсы и отнимают эту работу от них, направляя свою работу на потребности бизнеса, просто не то, что они хочу: Мы все дергаемся VB.

Ответ 7

Вероятно, причина, по которой он не привлек больше внимания, - это то, что мир J2EE настолько привык к тому, что он накладывает столько слоев на приложение, что обнаженные объекты встречаются как наивные.

Где наши услуги? Вы имеете в виду, что любой открытый объект дает мне немедленный доступ к базе данных? Что делать, если нам нужно было открыть приложение с вызовами RMI?

Кроме того, рынок не так много, потому что он ставит бремя разработки успешного приложения прямо на разработчиков приложений, а не на разработчиков инфраструктуры:)

Ответ 8

Гарет делает отличные очки.

Существуют и другие проблемы, такие как тот факт, что трудно контролировать внешний вид и они несовместимы с людьми, которые привыкли к модели окна. Существует также проблема моделирования, в которой не все области приложений хорошо подходят для прямого представления объектов.

Общая модель "программиста-гражданина", как это делается в сообществах с небольшим населением и голыми объектами, также вызывает сомнение. Большинство пользователей, похоже, не очень беспокоятся об изменении самих функций, поэтому мышление в объектах не так полезно.

Ответ 9

• Широкое использование технологии не имеет сильной корреляции с технологическим качеством.
• Систему nakedobject сложно использовать в сочетании с объектами типа: если я продаю разные виды продуктов и нуждаюсь в разных данных для разных продуктов, трудно ограничить данные по типу продукта.
• НЕТ потерянных импульсов при переключении лицензий. (для GPL + Commercial, а не недавний переход к Apache).

Вы посмотрели на jmatter?

[править] И еще один: это делает очевидным для не-программистов, если вы можете доставить. Spring очень много в технологической области, NO означает, что разработчик должен говорить с пользователями. Крупные организации этого не делают.

Ответ 10

NakedObjects (NO) хороши для быстрого прототипирования. Вы можете сосредоточиться на модели домена, не обращая внимания на GUI, DB и другие части вашего решения. Для производства он требует много улучшений (исправление ошибок, сопоставление данных, gui и т.д.) В самой структуре NakedObjects.

Итак, если вам нужно получить какое-то "доказательство концепции" для вашего решения, вы можете использовать NO. Но для производства готовы вкладывать ресурсы в разработку структуры НЕТ.

Кстати, в последнее время мы работаем над созданием средства просмотра DnD на основе GWT для NO 4.0.