Явные объекты. Хороший или плохой [закрытый]

Это успешно использовалось здесь в Ирландии .

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

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

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

1) 'Платформа только просит, чтобы Ваши объекты области (POJOs) были разделены на подклассы от AbstractDomainObject, это - все проводное соединение минимума'.

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

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

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

3) 'Общая модель citzen программиста, как поддержано в smalltalk и явных объектных сообществах...'. Мы никогда не поддерживали ту идею, и я не соглашаюсь с нею. Явные Объекты не об ободрительных пользователях к программе. Я верю твердо в роль профессионального разработчика - Явные Объекты просто помогают им записать лучшее программное обеспечение и более продуктивно.

Richard

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

сила Явного Objectsis, что Вы структурировали GUI согласно Вашей модели данных бесплатно. Недостаток - то, что типичный пользователь не думает о своем процессе как набор записей.

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

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

Между прочим, существует веб-опция рендеринга; см. демонстрацию в Явная Демонстрация Объектов .

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

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

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

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

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

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

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

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

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

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

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

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

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