Голые предметы. Хорошо или плохо

Question

Я недавно подвергался воздействию голых предметов. Похоже, довольно приличный каркас. Однако я не вижу его в широком распространении, как, скажем, Spring. Так почему же этот фреймворк не получает какого-либо кредита на основные приложения? Каковы его недостатки, как вы видите?

Answer 1

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

Хорошо:

• Автоматически генерирует DnD UI для ваших доменных объектов, как то, что db4o делает для сохранения.
• По словам создателя паттерна MVC, именно таким должен был быть MVC.
• Фреймворк только требует, чтобы ваши доменные объекты (POJO) были разделены на подклассы из AbstractDomainObject, то есть всей минимальной разводки.
• Фреймворк поддерживает конвенциональную конфигурацию OVER: множество аннотаций, никаких сумасшедших конфигурационных файлов XML.
• Прекрасно работает для создания прототипов вместе с db4o для персистентности.
• Из коробки функциональность для Hibernate.
• В моем случае мне потребовалось около 30 минут от приложения Download to Hello world. (IntelliJ IDEA IDE)
• Развертывание в виде JNLP, автономного, Web (NOX встроенного Jetty или Scimpi) и Eclipse RCP.
• Команда NOF всегда рядом с вами, когда вы просите о помощи на форумах.
• Naked Object Pattern - это отличная идея, сделайте себе одолжение и не торопитесь с этим.
• В графическом интерфейсе перетаскивания происходит множество проблем с юзабилити, но если ваши потенциальные конечные пользователи просто не смогут работать с интерфейсом DnD, то у вас все равно будут большие проблемы.

Плохо:

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

Вроде некрасиво

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

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

• Veikko

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Обнаженные объекты не требуют, чтобы доменные объекты были разделены на подклассы из AbstractDomainObject, хотя, как правило, это наиболее удобная вещь.

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

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

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

Ричард

Answer 5

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

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

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

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

Кстати, есть опция веб-рендеринга; посмотрите демоверсию в разделе " Голые предметы".

Answer 6

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

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

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

Answer 7

Гарет делает отличные замечания.

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

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