Обнаженные объекты. Хорошо или плохо

Question

Недавно я был открыт для обнаженных объектов. Это выглядит довольно прилично. Однако я не вижу его широко распространенным, как, например, Spring. Итак, почему эта структура не получает никакого основного кредита приложения. Каковы его недостатки, как вы видите?

Answer 1

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

Хорошая:

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

Плохая:

• None, что я могу думать.

любопытное уродливые:

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

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

• Veikko

Answer 2

Был успешно использован here in Ireland.

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Кстати, есть опция веб-рендеринга; см. демонстрационную версию на Naked Objects Demo.

Answer 5

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

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

Плюс есть не столько на рынок, потому что она ставит бремя разработки успешных приложений прямо на разработчиков приложений не каркасные разработчики :)

Answer 6

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

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

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

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

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

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

Ричард

Answer 7

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

Вы взглянули на jmatter?

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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

Менеджеры прикреплены к моделям и предоставляют CRUD и любые общие операции над коллекциями, такие как многократные запросы (дайте мне последние пять сообщений в блогах, самые распространенные теги и т. Д.), Массовые операции удаления \ обновления и бизнес-логику по случаям. Wow!

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

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

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