Spring Framework 2.5

>Вы шо шутите чтоли? Если бы спринг что-то такое гдето запрещал на таком уровне - он бы и нахре никому нужен не был как закрытая среда. Уж не говоря о том что такое даже теоретически трудно представить.

А вы попробуйте :) получить в ЖСП аппликейшен контекст который ему никто не давал. то что вы можете заинстанцировать _какой-то_ бинфектори еще не означает что это будет _этот_же или хотя бы даже _похожий_ бинфектори. вам еще как минимум нужно будет найти ресурс в котором лежит определение бинов...

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

и что во всех возможных МВС реализациях свет клином сошелся на ЖСП? а что делать если используемая для вью технология принципиально не может вызывать какие либо методы, включая бизнес-методы? пример? XSLT. чем плохая технология для вью? при этом я _убежден_ что _всё_ что должен делать вью - это внешний вид и дизайн. я считаю аксиомой то что дизайн должен быть _отделен_ и _абстрагирован_ от бизнес-логики. и XSLT этому требованию отвечает идеально. как мне вызывать бизнес-методы из XSLT? извращаться? писать расширения к XSLT-процессору? URL-handler'ы? это будет правильно? не проще ли просто дать на вход XSLT уже готовое DOM-дерево и не морочить себе голову лишними проблемами? что тут неправильного будет? и чем отличается от такого подхода использование JSP?

помоему вы сами делаете то в чем обвиняете других - создаете себе сначала какие то надуманные технологические проблемы а потом мужественно с ними боретесь

>Это прекрасно! А что вас не затруднит обосновать ужас?

легко. ужас это когда во вью предназначенном для анонимуса будет вызван бизнес-метод из админки... причем в продакшене))) вас это не пугает? меня - очень.

>Читайте свои ссылки - там же все написано.

то что там совпадает "что-то" (какая то часть) еще не значит что там совпадает "всё". вы про то что контроллер и вью тесно связаны между собой и практически созданы _друг_для_друга_ прочитали? поняли это? а то что модель совсем не _обязана_ быть активной читали? ах это в простейшем случае... а зачем мне какой либо более сложный случай? чтобы потом мужественно сражаться с технологическими проблемами? :) нет уж спасибо, я сначала попробую обойтись простейшими... по крайней мере в морде к базе данных :) или морде к базе данных даже МВС противопоказан? а что показано? Big JSP ?

>Ну, во-первых, не дата лэйера, а ModuleFacade. А во-вторых, почему-это фронт-энд не может подёргать методы ModuleFacade? Ведь фасад для фронт-энда и пишется.

фронтенд может. но фронтенд это не вью и особенно не ЖСП. фронтенд это вся МВС-триада. бекенд вообще не должен знать кто его будет дергать. так будет лучше для всех. задача бекенда быть настолько недоступным чтобы его дернуть могли только избранные. поэтому во фронтенде дергать бекенд может и должен только соотвествующим образом сконфигурированный для этого контроллер. который знает что он дергает и зачем.

>У меня сейчас идут два проекта, в которых я пробую этот способ доступа к данным. Один - поменьше, и тут я попробую обкатать этот метод (я тут и архитект и девелопер). В проекте побольше можно будет ещё что-нибудь поменять, если метод себя не оправдает (тут я почти не девелоплю).

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

>VO (или DTO) - довольно неприятная вещь. Я столкнулся с ним на предыдущем проекте, где он, действительно, использовался для борьбы с кривым ремотингом (архитектуру делал не я, и иногда мне кажется, что этот кривой ремотинг, может, специально воткнули в архитектуру, чтобы гарантировано отцепить фронт-энд от бэк-энда).

что конкретно было вам неприятно в ДТО? я не утверждаю что ДТО это самое приятное наслаждение. ДТО это ДТО. не более того. так что именно вам было неприятно?

>Хотя, если отказаться от ДТО насовсем, то возникает ряд проблем с вью: мы используем JSF в обоих проектах. И в JSF есть EL, который предоставляет возможность лазить по свойствам объектов. Вот тут то и возникает проблема: как воткнуть вызов к ModuleFacade, когда в EL написано "#{hotel.getRoomTypes}".

дык :)

>Или как по-другому решить эту проблему?

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

>Да. Это значит что вы связали данные с особенность реализации.

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

>получить в ЖСП аппликейшен контекст который ему никто не давал.

Bean factories and application contexts are often associated with a scope defined by an application server or web container, such as: * A Servlet context. * A Servlet.

>что это будет _этот_же или хотя бы даже _похожий_ бинфектори.

Серьезно? Спринг Мистификейшен - он мне не даст инстанциировать нужный мне класс.

>вам еще как минимум нужно будет найти ресурс в котором лежит определение бинов...

Мама моя родная. Класс в жаве без спринга инстанции ровать уже нельзя. Е мое - куда катится мир.

>о все таки для этого вам придется приложить довольно значительные и _нетривиальные_ усилия.

Вы так говорите как будто спринг будет защищать какой-то мистический код, который пишет какой-то мистический спринг-маг, а я как злобный орк буду замок штурмом брать. Да _я сам_ автор этого кода. Я сам создам какие мне угодно бины. Я сам определю модель доступа к ним. Я получу доступ к ним окуда захочу. И будет все это элементарно просто.

>да и зачем дизайнеру забивать себе голову бизнес-методами? у него (дизайнера) _совсем_ другая задача

От это мне все сказало. Вы дальше фреймворков видели когда нибудь что нибудь? MVC никакого отношения и привязки к вебу не имеет. Никакой дизайнер никогда в жизни не нарисует JSF/JSTL/XSL и прочие теги. Никогда в жизни дизайнер не задействует свои телепатические способности чтобы вычислить структуру данных которую ему надо отобразить которая у вас лежит в контексте.

>и что во всех возможных МВС реализациях свет клином сошелся на ЖСП?

Вот именно. И то елси ваш контроллер чего-то там кладет в request scope никак не парит если клиент там не jsp. А значит контролер такой - не нужен.

>при этом я _убежден_ что _всё_ что должен делать вью - это внешний вид и дизайн.

Дизайн чего? Внешний вид чего? Ответ - модели. ЗАдача View показать состояние модели. Все.

>как мне вызывать бизнес-методы из XSLT? извращаться? писать расширения к XSLT-процессору? URL-handler'ы? это будет правильно?

ТАк и скажите - не умеете. URL Reslover - реализация одного метода в одном интерфейсе.

>не проще ли просто дать на вход XSLT уже готовое DOM-дерево и не морочить себе голову лишними проблемами?

Не морочте. Не умеет делать други источники кроме дома для трансформации - ваше дело.

>помоему вы сами делаете то в чем обвиняете других

Я данные в контроллерах не готовлю для View. Меня не трогает MVCстость вебфреймворка и комплексы по этому поводу у разработчиков которые считают что если фреймворк каким-то боком не MVC то он плохой, в основном по причине того, что сам MVC не ложиться удобно на веб. Код декаплинг нужен для увеличения модульности с целью последующего code reuse. В вебпроектах такого бывает мало. ТАм где бывает достигается не посредством псевдоMVC как у спринга, где все жестко связано.

>оздаете себе сначала какие то надуманные технологические проблемы а потом мужественно с ними боретесь

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

>легко. ужас это когда во вью предназначенном для анонимуса будет вызван бизнес-метод из админки... причем в продакшене))) вас это не пугает? меня - очень.

А у вас как разработчика неконтролируема рефлексия? Вы в реализацию презентейшена для анонимуса вставляете методы для админа? Откуда они там возьмутся? Это во первых. А во вторых - что для вас секурити? Пейджа логина? Если каким-то мистическим образом этот админский метод таки дернется из под нетого пользователя все что он увидит это будет 403 Access Denied (SecurityException).

>то что там совпадает "что-то" (какая то часть) еще не значит что там совпадает "всё".

Там 100% совпадают функциональные роли компонентов.

>вы про то что контроллер и вью тесно связаны между собой и практически созданы _друг_для_друга_ прочитали? поняли это?

Нет. Вы не правильно понимаете в чем. Контроллер связан со view в том смысле что он обрабатывает события приходящие с этого view. Вам опять мешает это увидеть веб. Это в вебе у вас протокол вызова контроллера - http. А в смолтолковском GUI или в Swing вам знаетели для этого переменные нужны которые указывают на экземпляры контроллеров, чтобы посылать сообщения об проишедших на view событиях. Вниметельнее читайте.

The View - Controller Link

Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. _Instance variables_ in each maintain this tight coupling. A view's _instance variable controller points at its controller_, and a controller's instance variable view points at its associated view. !!!!And, because both must communicate with their model, each has an instance variable model which points to the model object!!!. So, although the model is limited to sending self changed:, both the view and the controller can send messages directly to each other and to !__their model___!.

>или морде к базе данных даже МВС противопоказан?

А что MVC это ваше все? В морде к базе данных ручная разработка этого всего - противопоказана.

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

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

>А вы что DAO в наружу высталяете?

нет, я даже бизнес-лейер наружу не выставляю, а прячу его в контроллере фронтенда....

>А где тут с вязь?

возможно другая структура, и уж точно - другой диалект SQL

>О - это я вас хочу спросиь. Это же вы отдали наружу объект орма.

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

>Вот и мне это интересно. Выж достали аккаунт со всеми его синтетическими примари кеями которые нужны только в RDMBS и высунули его наружу чтобы над ним издевалися пользовательский код. Посему мне интересно услышать этот ответ от вас.

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

>НАзначение этого фасада обеспечить для presentation layer приемлемый API который абстрагируется от конкретного представления данных и сфокусирован на бизнесметодах. Если надо снять у пользователя бабло со счета - надо передать имя пользователя, сумму и вернуть исключение если бабла нет. Все. Что там внизу - WS, JDBC, EEJB, ORM, JPA или прочий страшный набор букв пользователь знать _не должен_. И выставлять объект типа аккаунт даже в виде Transfer Object наружу _не надо_.

c этим никто не спорит. спорят с тем что бизнес-лейер и дата-лейер - суть одно и то же (по вашим словам) и тем что фасад бизнес-лейера дергать нужно непосредственно и вью (по вашим же словам). или я что то не правильно понял в ваших словах? а по поводу выставления объекта типа аккаунт в виде ДТО - дык а что делать если нужно показать аккаунт? не в виде цифры а в виде всех атрибутов которые с ним связаны. вью будет для каждого атрибута дергать бизнес-метод? зачем?

>По ссылке там описание паттерна. Я его привел как пример техники. Если вы не можете оценить, что эта техника дает и видите только ее связь с EJB - мои соболезнования. То что там написано это не жуткая инновация в энтерпрайз леере - это принцип как делать нормальные интерфейсы к библиотекам (любым), с минимальным набором простых параметров, и well-defined interfaces, со скрытыми деталями реализации (encapsulation) и всем прочими фишками ООП.

не уходите от темы :) я спросил где написано что вью вызывает фасад? ведь вы мне фасад привели как пример того что должен вызывать вью... а то что интерфейсы должны быть велл-дефайнед это у меня сомнений не вызывает

>Да он в основном для него и нужен. Фасад это то что будет выставлено в наружу как вебсервис. А вы что собрались туда выставлять? Контроллер?!

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

Мой вопрос немного не в тему - просто любопытно.

r, когда ты успеваешь работать?

>Вы как специались по полиморфному поведению в ормобъектах конечно не затруднитесь запостить примеры?

терпение, уважаемый, терпение :) не всё сразу... какие конкретно примеры вам нужны? не затруднитесь уточнить? как замапить абстрактный класс и двух его наследников а потом получить коллекцию абстрактных классов в которой будут все наследники? или что?

>Вай вай вай. Если что-то breaks encapsulation - это не много не мало broken encapsulation, и хватит сказок, что энкапсуляции есть просто ее заоптимизировали до полного ее отсутствия.

отсутсвие инкапсуляции в данном случае и есть оптимизация. и если не быть ССЗБ то это отсутсвие не выйдет за пределы ОРМа. кто вас заставляет лезть внутрь ОРМа? это не нарушение инкапсуляции - копаться в кишках ОРМа?

>Когда я из соображения перфоманса перепишу программу с С++ на асм - она что останется объектной просто с "соображениями перфоманса"?

если правильно перепишите ( с сохранением архитектуры и дизайна ) - вполне. почему нет? другой вопрос удастся ли вам такое переписывание без серьезного нарушения архитектуры. ОРМ _может_ работать без нарушения инкапсуляции.

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

это ответ на вопрос почему плохо работать с разными объектами через один интерфейс? а в каких конкретно книгах вы такое почерпнули?

>Хорошо у меня есть свинговый DefaultTableModel - как мне его замапить на ORM?

а зачем вам его мапить? можете объяснить? он вобще для этого предназначен? свинговый класс этот.

>Еще хочу знать что это за id у меня в объектах - никаких id в доменной области нет. Как это понимать?

он вам мешает? ну спрячьте его в дата-лейере. дата-лейер кстати именно для этих целей и нужен как бы. чтобы прятать id. вы хотите сказать что то чем оперирует ОРМ это _чистые_ доменные классы не замутненные никакими деталями имплементации? да вы идеалист оказывается... чистыми доменными классами оперирует бизнес-лейер посредством дата-лейера который в свою очередь прячет детали имплементации. разве нет?

>Отсутвие полиморфного поведения.

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

>возможно другая структура, и уж точно - другой диалект SQL

А что у вас VO/DTO как-то влияет на диалект sql и vice versa?

>а это именно то о чем вы спрашиваете.

Нет - я спрашиваю каким это образом у вас дата леер стал независимым если вы его объекты отдаете в снаружу (хотя быв и в виде VO)? От чего тогда он независим? От диктата США?

>а по чем бизнес-лейеру видно что это именно синтетический праймари кей?

Да мне все равно видно ли ему это вообще, важно что раскрыта детал реализации - Acсount объект представляющий запись в базе данных о пользователе в реляционной модели. Кто вам сказал что при этой вашей замене бекэнда на не реляционный объектная модель будте та же? Может там запись о полтзователе со всеми его счетами будет вообще в одной XMLине. Или вообще заменена на другую подсистему где надо будет звать веб-метод а не сохранять в базу? А вы этот объект, да на клиентскую машину. Это сколько ж софта патчить/пересобирать надо? Весь?

>c этим никто не спорит.

А кто тут выступал за VO?

> спорят с тем что бизнес-лейер и дата-лейер - суть одно и то же (по вашим словам)

процитировать слабо?

>и тем что фасад бизнес-лейера дергать нужно непосредственно

Да. Его для того и изобретали.

>ли я что то не правильно понял в ваших словах?

Если вы перечитаете пост другого анонимуса про гостиницы и ?свою? рекомендацию про VO вы обнаружите что вы вытянули VO/ORM модель за пределы бизнесфасада. Мои слова очевидным образом возражают против подбного произвола.

>а по поводу выставления объекта типа аккаунт в виде ДТО - дык а что делать если нужно показать аккаунт?

В поставленном примере аккаунт это сумма.

>вью будет для каждого атрибута дергать бизнес-метод? зачем?

Где вы там разглядели атрибуты?

>я спросил где написано что вью вызывает фасад?

Где вы там вообще нашли упоминание view? Эьтот паттерн касается сокрытия деталей реализации миддл таер.

>ведь вы мне фасад привели как пример того что должен вызывать вью...

Именно. Этот фасад может вызывать view, может звать удаленный толстый клиент, этот фасад может быть выставлен в качестве вебсервиса и т.д.

>а то что интерфейсы должны быть велл-дефайнед это у меня сомнений не вызывает

А снять бабки с осчета в виде

a = x.getAccount("vasia"); a.setValue(a.getValue() - 50); x.store(a);

это по вашему well defined interface для подобного рода операций?

>в качестве веб-сервиса? именно его. контроллер

Чего-чего? Вот этот?:

public interface Controller {

/** * Process the request and return a ModelAndView object which the DispatcherServlet * will render. */ ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws Exception;

}

Что-то у меня сомнения что он вопервых вкурит SOAP а вовторых клиент врубит что за ModelAndView ему приполз в ответ.

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

Вообще то вы качестве посыпанного сахаром он и нахрен никому не нужен. Фасад это интерфейс к модулю и он собствено и представляет единый корректный интерфейс взаимодействия с модулем.

>r, когда ты успеваешь работать?

я болею счас;)

я вам про веб-сервис больше скажу. веб-сервис это не более чем морда к базе данных, и следовательно в веб-сервисе _тоже_ должен быть свой уровень презентейшина со своим МВС. откуда следует что через веб-сервис должно быть доступно _всё_? фасад решит эту проблему? каким образом?

сериализацю ХМЛ кто делает? вот это и есть вью. что сериализируется? это и есть модель. кто решает что будет сериализироваться а что нет, принимать параметры, проверять их, передавать в бизнес-лейер - вот это и есть контроллер.

>как замапить абстрактный класс и двух его наследников а потом получить коллекцию абстрактных классов в которой будут все наследники? или что?

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

>отсутсвие инкапсуляции в данном случае и есть оптимизация.

Ага - значит вычеркиваем еще одно из основопологающи свойств ОО из орма. Че осталось? Мессадж пассинга никто не искал. Энкапсюляцию вычеркнули - внешняя система знает внутрене устройство и манипулирует им. Работа через интерфейсы отсутсвует - орм заоптимизирован до копания в кишках. Про код реюс и говорить не приходится с реляционными ключами внутри. Что осталось согласно Алану Кею ? А ниче не осталось. ЧИСД. Когда вычеркнем полиморфизм (а вместе с ним и наследование учитывая что реюза кода не происходит в связи его полным отсутствием) ничего не останется и с точки зрения его известных последователей.

> если правильно перепишите ( с сохранением архитектуры и дизайна ) - вполне. почему нет

Это че - дизасемблирую что ли? Де там будет перфоманс если все сохранено? Орм перфомансит как раз мимо ООП.

> это ответ на вопрос почему плохо работать с разными объектами через один интерфейс?

Где у вас один интерфейс? Это тот который к VO и ORMO? ТАк вы не те интерфейсы дизайните - почитайте предидущего оратора и его архитектуру - вот он дизайнит те.

>а зачем вам его мапить? можете объяснить? он вобще для этого предназначен? свинговый класс этот.

Вы ж тут распинаетесь что я к любой модели орм примаплю. Мне вот интересно выводить в табличку содержимое. Хочу примапить DefaultTableModel. Что тут неяснго? Это модель табличного отображения. Не помошник мне орм да? ТАки не на любую модель можно мапить? А на согласуюбщуюся со структурой BD? И тесно с ней связанную?

>вы хотите сказать что то чем оперирует ОРМ это _чистые_ доменные классы не замутненные никакими деталями имплементации?

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

>да вы идеалист оказывается...

К стати я такой мрачный идеалист, что у меня такие классы наличествуют в двух больших проектах. Только там орма нет. И синтетических ключей нет. Сюрприз: для указателей в памяти они не нужны. Второй сюрприз: class-per-table декомпозиция нужна только для маппинга в реляционную базу. Стоит убрать стереотипы - и как все просто становится - ни синтетика ненужна, и объекты становятся чистыми и т.д.

>откуда следует что через веб-сервис должно быть доступно _всё_? фасад решит эту проблему? каким образом?

А фасад по вашем это такой мегакласс который делает все? Это набор хорошо продумманных интерфейсов. Что вам не надо на вебсервисе - не экспозите как вебметоды.

>сериализацю ХМЛ кто делает?

Транспорт. SOAP.

>то сериализируется? это и есть модель.

Ни разу. Результат запроса о состоянии модели.

>я болею счас;)

а ну извините, тогда вы здесь вне конкуренции..) а вот мне еще и работать приходится... :(

наверное вам придется подождать пока я тоже приболею малось тогда и поговорим по понятиям :))

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

>Что вам не надо на вебсервисе - не экспозите как вебметоды.

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

>А что у вас VO/DTO как-то влияет на диалект sql и vice versa?

вы что потеряли нить рассуждений? на диалект влияет база данных (платформа РДБМС). поставили задачу - кроссплатформенность. как решать? ОРМ - абстрагирует всё? отлично. а если кросплатформенность должна распространятся и на используемые/неиспользуемые ОРМы? то есть - приложение должно легко работать как с любым ОРМом так и без ОРМа тоже. фантастика? думаю нет. вполне себе здоровое требование любого наивного заказчика. проблема сделать? проблема но сделать можно. просто изолируем платформенно зависимые вещи в _отдельном_ от бизнес-логики нижнем уровне который называем дата-лейером ака ДАО. а вот дата-лейер уже экспортирует наружу ДТО для бизнес-уровня. Чтобы нежный и чувствительный бизнес-уровень не боялся ужасов физического аспекта хранения данных.

>Нет - я спрашиваю каким это образом у вас дата леер стал независимым если вы его объекты отдаете в снаружу (хотя быв и в виде VO)? От чего тогда он независим? От диктата США?

Не дата-лейер независим, а его клиенты - бизнес-лейер например (и в идеале он должен быт единственным клиентом дата лейера). вас это пугает?

>А кто тут выступал за VO?

а каким боком например фасад противоречит ДТО? или что вы предлагаете возвращать из бизнес-лейера через фасад? заОРМленные записи из базы? домайн-модель? а что домайн-модель у вас не замаплена ОРМом? а, голую цифирь... ну знаете ли не всё в жизни к сожалению так просто как хотелось бы... или вы любитель прокрустовых лож?

>процитировать слабо?

да слабо. почитайте свои посты и увидите.

> Где вы там разглядели атрибуты?

атрибутами является номер аккаунта, ФИО владельца и прочие интересные вещи. к чему упомянутая вами цифра относится вообще? она абстрактная? у нее владелец есть? тот который может прийти и обнулить нафиг этот аккаунт например.

>a = x.getAccount("vasia"); a.setValue(a.getValue() - 50); x.store(a);
>это по вашему well defined interface для подобного рода операций?

смотря для кого. для бизнес-лейера - очень велл я считаю. а вы о чем спрашиваете? про ЖСП что ли?

>public interface Controller {
>Что-то у меня сомнения что он вопервых вкурит SOAP а вовторых клиент >врубит что за ModelAndView ему приполз в ответ.

для вас контроллер означает именно этот интерфейс? извините не знал. _этот_ интерфейс - это абстрактный контроллер для HTML клиентов. и SOAP вобщето далеко не единственный и совсем не самый лучший способ сделать веб-сервис. и если какой то конкретный SOAP реализован без MVC это еще не значит что все возможные веб-сервисы обязаны быть именно такими. мне вот например REST нравится. для AJAX самое то. а если говорить об AJAX+XSLT то вобще хорошо. а SOAP это новая ипостась для RPC (тоесть соап это тоже буззворд). из того что у вас есть возможность организовать PRC через соап совсем не следует что теперь все должны этим заниматься. вы видимо питаете особую симпатию к толстым клиентам? это бывает...

>Вообще то вы качестве посыпанного сахаром он и нахрен никому не нужен. Фасад это интерфейс к модулю и он собствено и представляет единый корректный интерфейс взаимодействия с модулем.

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

вот давайте чтобы вернуть разговор в более менее конструктивное русло возьмем вот этот простой юзкейс - банковская выписка. надеюсь вы видели когда нибудь банковскую выписку? если нет - поясню: в ней в частности приводится весь перечень операций которые были произведены по текущему счету за период. вот расскажите мне как будет выглядеть (примерно, детали можем уточнить отдельно) ваш фасад? для абстракции мы даже не будем уточнять каким (пока, если будет нужно - уточним) конкретным образом будет потом использоваться фасад - жсп, соап или локальный свинг. слабо?:) без ДТО естественно и без побочных еффектов от ОРМа и без прочих некошерных показываний наружу внутренних деталей имплементации. всё должно быть предельно абстрактно и соответсвовать принципам ООД.

надеюсь это будет не нечто подобное

int getOperationsCount();
String getOperationFrom(int operationNum);
String getOperationTo(int operationNum);
int getOperationAmount(int operationNum);
String getOperationCurrency(int operationNum);
...

или все таки так и будет? если да - это оччень объектно и высокоуровнево, я поражен

помоему так можно и на C (даже без плюсов) и даже на ассемблере сделать всё

>вот у вас в есть мифический getAccount(), так?

Нету. У меня есть balance, withdraw, etc.

>кто проверит кому показывать _этот_ аккаунт а кому нет?

спецификаций по теме - куча; лукцию по вебсервисам читать - облом. Самый простой способ - тот же что и в вебе, через соответствующие хеадеры запроса. Механизм абсолютно аналогичный как и на вебе. Плюс куча дополнительных. У вас как проблем с доступом к вебстраницам нет? Вот и тут не будет.

>наче какой смысл вы вкладываете в понятия фасада и контроллера? чем они отличаются? ничем?

Фасад представляет собой фронтеэнд бизнеслогики, часть модели. Контролер реагирует на действия пользователя из view. Если я буду реализовывать толстого клиента для WS, то view, контролер -> клиент, model (черезх клиентский прокси) -> server.

а по поводу того что вам позволяет и чего не позволяет спринг - так а что вам даст инстанцированние класса? какой класс вы собрались инстанцировать? jndi datasource что ли? а класслоадер вам это позволит делать в ЖСП? вы уверенны? я вот лично нет...

спринг не только создает бины, он еще их _менеджит_. что даже более важно чем создавать. например он менеджит зависимости между ними. что и называется депенденс инжектинг. а вы что думали? и _то_ каким именно образом ассоциируются контексты сервлетов и спринга это вопрос внутренней политики и архитектуры. в жсп никто никакого контекста из спринга обычно не отдает. по крайней мере явно. а при необходимости это можно и особым образом предотвратить. всё что отдают в жсп - модель. а модель это обычно самые что ни на есть ДТО. но ни в коем случае не доменные бины. обычно.

>>a = x.getAccount("vasia"); a.setValue(a.getValue() - 50); x.store(a);
>>это по вашему well defined interface для подобного рода операций?

>смотря для кого. для бизнес-лейера - очень велл я считаю. а вы о чем спрашиваете? про ЖСП что ли?

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

кто будет клиентом (не сервером) приведенного вами АПИ? бизнес-лейер? тогда велл. подобный апи очень хорош в качестве интерфейса к дата-лейеру. его будет использовать бизнес-лейер чтобы имплементить бизнес-логику. а фронтенд уже получит фасад к бизнес-лейеру через withdraw(). но вью (жсп) никоим образом не будет вызывать withdraw(), и не надейтесь :) withdraw() будет вызывать контроллер и результат через ДТО модель будет передавать во вью. это если говорить о данном конкретном вопросе. так думаю будет понятнее что я хотел сказать выше.

>фантастика? думаю нет.

Вообще-то действительно фантастика:) Но это к слову.

>Чтобы нежный и чувствительный бизнес-уровень не боялся ужасов физического аспекта хранения данных.

ТАк что ж вы передаете VO для ORMO в снаружу? Ведь он же непосредственно является отображением физической структуры хранения.

>Не дата-лейер независим, а его клиенты - бизнес-лейер например (и в идеале он должен быт единственным клиентом дата лейера). вас это пугает?

42 раз задаю вопрос - каким образом они независимы, если обект которым управляет ORM или его точный прообраз (VO), который все равно отражает маппинг на реляционную структуру передается во внешнюю среду?

>а каким боком например фасад противоречит ДТО?

Таким что DTO является точным отражением ORMO, содержит всякие ключи и тд и как следствие привязывает пользовательский код к дата лееру.

>атрибутами является номер аккаунта, ФИО владельца и прочие интересные вещи. к чему упомянутая вами цифра относится вообще?

К вопросу. Вопрос звучал так - "нука скоко бабла на счете васи?"? Ответ ожидается 53 доллара. А не сложный сериализованный объект с первичными ключами базы данных. Догадайтесь что я с ними смогу сделать из внешнего кода, если являюсь 3rd party по отношению к вашему коду. setAccessible, setKey(счет моего соседа),setValue(0), store. >смотря для кого. для бизнес-лейера - очень велл я считаю. а вы о чем спрашиваете? про ЖСП что ли?

Для лбого внешнего по отношению к библиотеке кода.

>для вас контроллер означает именно этот интерфейс? извините не знал.

Это MVC спринга который вы так хвалите, и интерфес того контролера который вы собрались выставлять в снаружу для WS. Или он уже не подходит вместе спринг вместе с его MVC для поставленной задачи?

>и если какой то конкретный SOAP реализован без MVC

"конкреный SOAP" вообще отношения к этому не имеет. Вопрос в том что выставлять в качестве вебсервиса. JBoss например умеет экспосить SessionBeans в качестве WS. Контролерами обычно выступают сервлеты, action(Struts), Controller (Spring). Чтото я не видел чтобы мысль экспозить их в качестве WS вообще кому-то в голову приходила.

>мне вот например REST нравится

REST тут вообще перпендикулярен.

>SOAP это новая ипостась для RPC (тоесть соап это тоже буззворд).

Только это очень популярный RPC и очень кросплатформенный и стандартизированный. К вашему сведенью очень рабочий.

>з того что у вас есть возможность организовать PRC через соап совсем не следует что теперь все должны этим заниматься

Это стоит понимать так что на вопрос каким образом вы собрались экспозить заявленный контролер в качестве вебсервиса ответ "а нафига нам вебсервисы"? Тот же вопрос относительно: RMI, CORBA, JAX-RPC, etc.

>вы видимо питаете особую симпатию к толстым клиентам? это бывает...

У меня нет симпатии к толстым клиентам. У меня есть толстые клиенты. Они знаете ли часто выступают в качестве софта работающего на клиентских машинах. Или вы AJAX в кварк интегрировать собрались или устанавливать в качестве виртуального принтера? Или анализировать и трансформировать клиентские файлы на бровзероном джаваскрипте будете, а потом отсылать их на чужие FTP?

>какую "простую примитивную цифру" мне вернет ваш чудесный фасад.

Выписку. XML, PDF, Objects. А не набор записей транзакций с первичными ключами клиента.

>а класслоадер вам это позволит делать в ЖСП? вы уверенны? я вот лично нет...

А я вот лично да (учитывая что свои IoC контейнеры писал не раз со встроенными вебсерверами которые деплоят совсем не варфайлы и классы ищут там где мне надо). Советую почитать архитуктуру класслоадеров вебконтейнеров.

>спринг не только создает бины, он еще их _менеджит_.

Спринг это не магия благодаря которой мы что-то можем - это фреймворк который облегчает нам что-то сделать. Дапример занимается DI. Это что отменило оператор new ?

>а вы что думали?

Я думаю что это не магия а всего лишь Class.forName. class.getMethod("set...").invoke. Вы переоцениваете мистицизм спринга.

>в жсп никто никакого контекста из спринга обычно не отдает.

JSP это сервлет из которого доступны все скопы в которые всунут спринг. И отдам я туда что захочу. И достану все что там лежит.

>а при необходимости это можно и особым образом предотвратить.

Ага - спринг сессиями пользоваться перестанет и реквестами. С ума сойти.

>обычно.

Обычно - это в спринге согласно его архитектуре. Но не надо думать что нельзя делать по другому или что спринг это truMVC.

>Вот возьмем всеми любимый тут Лисп. Можно, например, выделить в Лиспе паттерн "ленивый список". Значит ли это, что Лисп отправляется в топку?

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

>Тут разве говорилось о "выделить паттерн" ? Выдели паттерн "бинарное дерево" !

Так какие проблемы? Паттерн "бинарное дерево, двунаправленое" - встречается при реализации многих алгоритмов.

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

Так и может. Только паттерны можно выделять уже на более высоких уровнях. Это такой метаязык получается.

>Когда я из соображения перфоманса перепишу программу с С++ на асм - она что останется объектной просто с "соображениями перфоманса"?

Для тебя будет новостью, но и на ассемблере можно писать объектно-ориентировано. Точно так же, как и на чистом С.

>Хорошо у меня есть свинговый DefaultTableModel - как мне его замапить на ORM?

Да без пробем. Берем и map'им через рефлексию, у меня в проекте такой адаптер используется.

>Еще хочу знать что это за id у меня в объектах - никаких id в доменной области нет. Как это понимать?

Читаем про "суррогатный ключ" и почему естественные ключи не стоит использовать в 99% случаев. Это относится к базовым принципам построеня реляционных баз данных, безотносительно наличия ORM.

>ТАк что ж вы передаете VO для ORMO в снаружу? Ведь он же непосредственно является отображением физической структуры хранения.

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

>42 раз задаю вопрос - каким образом они независимы, если обект которым управляет ORM или его точный прообраз (VO), который все равно отражает маппинг на реляционную структуру передается во внешнюю среду?

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

>Таким что DTO является точным отражением ORMO, содержит всякие ключи и тд и как следствие привязывает пользовательский код к дата лееру.

это из чего вдруг следует что ДТО являются _точным_ отражением ОРМО и _содержит_ "всякие ключи" ? в какой книге вы это прочитали?

>>какую "простую примитивную цифру" мне вернет ваш чудесный фасад.
>Выписку. XML, PDF, Objects. А не набор записей транзакций с первичными ключами клиента.

Objects? какие объектс ? o_O
ORMO, DTO или что то мистическое??

>никто не показывает _дата-лейеру_ никаких внутренних данных которые не имеют отношения к логической модели.

сорри, бизнес-лейеру не показывают (неотносящиеся к делу внутренние аспекты)

>А я вот лично да (учитывая что свои IoC контейнеры писал не раз со встроенными вебсерверами которые деплоят совсем не варфайлы и классы ищут там где мне надо).

_ваш_ ИоК - _может_быть. вы со спрингом вообще работали? много раз?

>Советую почитать архитуктуру класслоадеров вебконтейнеров.

вам я тоже это советую. особенно по аппликейшен контейнерам.

>Спринг это не магия благодаря которой мы что-то можем - это фреймворк который облегчает нам что-то сделать.

"любая достаточно современная технология неотличима от магии" - Артур Кларк (цитата не точная).

>Дапример занимается DI. Это что отменило оператор new ?

какое отношением имеет к ДИ оператор нью? они _никак_ не связаны. ДИ может связывать бины из _разных_ класслоадеров. благодаря ДИ у контроллера есть ссылка на объект который сам _контроллер_ не смог бы создать никоим образом. и эту ссылку контроллер во вью ни за что не отдаст. это понятно? так же во вью нет доступа к контексту спринга. все что у вью есть - ДТО-модель.

>Я думаю что это не магия а всего лишь Class.forName. class.getMethod("set...").invoke. Вы переоцениваете мистицизм спринга.

вот как раз _этот_ код к спрингу имеет меньше всего отношения. его имплементит apache-common-beans. спринг он вестма значительно более высокоуровневый.

>JSP это сервлет из которого доступны все скопы в которые всунут спринг. И отдам я туда что захочу. И достану все что там лежит.

контекст спринга к скопам отношения не имеет. вы удивлены? как раз именно в скопы их помещает спринг. причем в разные скопы разные бины. и только те которые относятся к этому скопу.

>Ага - спринг сессиями пользоваться перестанет и реквестами. С ума сойти.

какой именно спринг? ИоК? ИоК _непользуется_ никакими сессиями и реквестами. откуда у ИоКа вообще может быть какая то сессия?

сессиями и реквестами пользуется МВС. и то как он это делает - вопрос вполне решаемый. а вот сам по себе ИоК легко позволяет вам дать по рукам.

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

>Обычно - это в спринге согласно его архитектуре. Но не надо думать что нельзя делать по другому или что спринг это truMVC.

я и сказал что обычно в спрингею да и в спринге это тоже может быть не обычно вполне. и без спринга это может быть обычно. быть может всё. вопрос в другом - что _должно_ быть а чего быть _не_должно_. естественно в данном конкретно взятом (это переменный фактор) контексте (задаче то есть).

>Читаем про "суррогатный ключ"

Где читаем? В какой книжке? Я нигде такого не встречал. У Кодда?

>и почему естественные ключи не стоит использовать в 99% случаев.

Почему? Кодд об этом ничего не пишет. Где это можно прочитать?

>Для тебя будет новостью, но и на ассемблере можно писать объектно-ориентировано. Точно так же, как и на чистом С.

Между "объектно-ориентированно" и "с классами" - 2 большие разницы. Что дял тебя будет новостью.

>Да без пробем. Берем и map'им через рефлексию, у меня в проекте такой адаптер используется.

Конфиг гибернейта в студию.

>Читаем про "суррогатный ключ" и почему естественные ключи не стоит использовать в 99% случаев. Это относится к базовым принципам построеня реляционных баз данных, безотносительно наличия ORM.

Именно! _Реляционных_ баз данных. А не предметных областей. И не объектных моделей предметных областей. Вот и все - ты сам связал своюб модельку с _реляционной базой данных_. Неразрывно. Так что сливайте воду пишите письма.

>дата лейер по вашему чем вообще занимается? помоему он занимается что _опосредованно_ отображает физическую структуру.

Орм является отображением структуры хранения, а не структура хранения отражением орма. Если выкинуть RDBMS из бекэнда структурка то перерисуется.

>в виде _логической_ а не физической модели данных...

Вы или не дочитали или хрен вас знает. VO никаких логических структур не возвращает. Кончайте придумывать про конкретные паттерны то что они не делают потому что вам так удобнее.

>не объект отражает реляционную структуру, а реляционная структура отражает объекты.

По 42 кругу одно и тоже - в объектных структурах нету никаких синтетических(суррогатных) ключей. Они нужны только для реляционной структуры. Реляционная структура и ее ограничения прямо влияет на вашу модель орма. Если думаете что не влияет - вперед сделайте связь между обектами без введения понятия ключей.

>в частности - никаких id в логической модели уже нет.

Серьезно? Код который вытаскивает VO за фасад а потом втаскивает обратно с целью сохранения в студию. Хватит описания механизма определения соотвтвти я обекта в памяти строке в базе данных при отсутствии первичного ключа в объекте.

>это из чего вдруг следует что ДТО являются _точным_ отражением ОРМО и _содержит_ "всякие ключи" ? в какой книге вы это прочитали?

Предлагаю ответить на вопрос выше о механизме.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

Вы что - придумываете под название паттернов их содержание как вам заблагорассудится?

>ORMO, DTO или что то мистическое??

Что-то мистическое. Как указывал коллега наверху в базе данных у него может быть информация о номерах с метками занят свободен. В ответ на запрос о вариантах предложения клиенту вернется список объектов в котором будет номер, описание, цена, спецпредложения, дискаунты, и т.д. что напрямую в кортеже отношения описывающем номера и отражающемся в ORMобъект Room _не хранится_ - половина этих данных вообще может быть вычисленными полями при чем в зависимости от фазы луны и имени клиента. Доступно?

>_ваш_ ИоК - _может_быть. вы со спрингом вообще работали?

А что у нас спринг уже стал вебконтейнером да? Он сам занимается развертыванием webapp? Он компилит JSPшки?

>вам я тоже это советую. особенно по аппликейшен контейнерам.

Я с ней знаком. Ваше замечание о том что мне из JSP не предоставят доступ к классу лежащему в WEB-INF говорит о том, что вы вообще ее не представляете.

>ДИ может связывать бины из _разных_ класслоадеров.

Найдете эти разные класслоадеры в спринге для классов лежащих в WEB-INF и JSP такие что один не является парентом другого?

>спринг он вестма значительно более высокоуровневый.

Серьезно? Советую глянуть на код инсттрументинга спринга для аспектов. Откроете много нового для себя по поводу высокоуровнести спринга.

>контекст спринга к скопам отношения не имеет. вы удивлены?

Я вам процитировал документацию спринга. Они врут?

>какой именно спринг? ИоК? ИоК _непользуется_ никакими сессиями и реквестами. откуда у ИоКа вообще может быть какая то сессия?

MVC. А вы тут про вьевы и контроллеры иока распинались?

>а вот сам по себе ИоК легко позволяет вам дать по рукам.

Зачем мне вообще иок? Без IoC уже нельзя класса инстанциировать?

>но вам видимо выгодно увести разговор в сторону чтобы не отвечать на уже заданные вопросы на которые вы не хотели бы отвечать...

Какие вопросы? Какая нафиг секурность? Спринг в вебе имеет 1 класс лоадер который заменяет WebAppClassLoader в контейнере для и инструментирования классов аспектами. Для справки и для пресечения дальнейшего бреда Servlet Specification 2.3 раздел 9.7.2 гласит: "The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics...." Это дает мне доступ к любому классу содержащемуся в WEB-INF/lib и WEB-INF/classes. Хватит уже сказок.

>Орм является отображением структуры хранения, а не структура хранения отражением орма. Если выкинуть RDBMS из бекэнда структурка то перерисуется.

для вас дата-лейер это и есть всего лиш орм? для меня дата лейер это ДАО (надеюсь не нужно пояснять что такое ДАО). орм _скрыт_ внутри ДАО. более того - в ДАО может не быть вообще никакого ОРМа. это уж как нам захочется. повторяю, задача дата лейера предоставить своим клиентам (бизнес-лейеру) _логическую_ модель данных и _скрыть_ физическую. поэтому никакой зависимости от реляционной модели вне ДАО в идеале уже нет (конечно могут быть какие то артефакты остаточные но это уже будет опять таки не более чем оптимизации)

>Вы или не дочитали или хрен вас знает. VO никаких логических структур не возвращает. Кончайте придумывать про конкретные паттерны то что они не делают потому что вам так удобнее.

я прочитал по диагонали приведенную вами ссылку на блюпринт и ответа на вопрос "почему ДТО _обязаны_ быть точно такими же как ОРМО" не нашел. процитируйте пожалуйста точную цитату. все что я нашел было что то типа такого

Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.

понимаете? _populate_

где тут требование _точного_ соответсвия ДТО реляционной модели? помоему вы в чем то тут ошибаетесь...

>Код который вытаскивает VO за фасад а потом втаскивает обратно с целью сохранения в студию. Хватит описания механизма определения соотвтвти я обекта в памяти строке в базе данных при отсутствии первичного ключа в объекте.

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

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

>Что-то мистическое. Как указывал коллега наверху в базе данных у него может быть информация о номерах с метками занят свободен. В ответ на запрос о вариантах предложения клиенту вернется список объектов в котором будет номер, описание, цена, спецпредложения, дискаунты, и т.д. что напрямую в кортеже отношения описывающем номера и отражающемся в ORMобъект Room _не хранится_ - половина этих данных вообще может быть вычисленными полями при чем в зависимости от фазы луны и имени клиента. Доступно?

это и есть бизнес-модель. создает её бизнес-лейер. каким боком тут ОРМ чему то может мешать я чесно говоря не очень понимаю. бизнес-лейер создает ДТО соотвествующий бизнес-модели а не модели дата-лейера. модель дата-лейера и бизнес-модель - вещи разные. презентейшн видит бизнес-модель, а не модель дата-лейера.

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

дабы уберечь вас от очередной ошибки в понимании мною сказанного думаю нужно добавить что

... но их (синтетических первичных ключей) нет в _интерфейсе_ который использует бизнес-лейер _для взаимодействия с дата лейером _

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

>Найдете эти разные класслоадеры в спринге для классов лежащих в WEB-INF и JSP такие что один не является парентом другого?

они не в спринге. они в нашем приложении.

>Я вам процитировал документацию спринга. Они врут?

они не врут. вы просто не совсем поняли то что цитируете.

>MVC. А вы тут про вьевы и контроллеры иока распинались?

в спринге MVC построен поверх ИоК.

>Зачем мне вообще иок? Без IoC уже нельзя класса инстанциировать?

как правило можно но не нужно. а иногда - нельзя.

>Какие вопросы? Какая нафиг секурность?

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

по поводу секюрности дальше. а тут скажу что все ваши аргументы ведут к тому что ЖСП это большая дыра в секюрности. и уже по этой одной причине ЖСП следует избегать. представьте себе приложение где пользователи должны иметь возможность менять свои темплейты дизайна.

> Спринг в вебе имеет 1 класс лоадер который заменяет WebAppClassLoader в контейнере для и инструментирования классов аспектами. Для справки и для пресечения дальнейшего бреда Servlet Specification 2.3 раздел 9.7.2 гласит: "The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics...." Это дает мне доступ к любому классу содержащемуся в WEB-INF/lib и WEB-INF/classes. Хватит уже сказок.

"спринг в вебе" легко дописывается нами так что становится несколько класслоадеров которые 1) для жсп и из-веб инф (стандартный) 2) для избранных сервлетов (точнее для контекста который инжектит в них бины) и не из веб-инф (защищенный)

точнее так:

"спринг в вебе" легко дописывается нами так что становится несколько класслоадеров которые 1) для жсп и из веб-инф/либ (стандартный) 2) для избранных сервлетов (точнее для контекста который инжектит в них бины) и не из веб-инф/либ, а скажем из веб-инф/секуре/либ (защищенный)

>_логическую_ модель данных и _скрыть_ физическую

Хватит твердить матру. Идите читайте описание паттерна VO/DTO. А то ваши инсинуации вокруг ваших скрытых архитектур уже настолько далеко от заяленного DTO что между нимин ничего общего нету.

>где тут требование _точного_ соответсвия ДТО реляционной модели? помоему вы в чем то тут ошибаетесь...

Читайте кто продьюсит DTO и кто его потребляет в обратную сторону.

Нет я конечно понимаю что у вы сейчас начнете утверждать что обект ORM или прочий EEJB не обязательно должен производить слепок исключительно себя а может строить нужные запросу логические структуры, я опять подниму вопрос о связи конкретной логики клиента с объектами орма с одной стороны, и перпендикулярную логику в с другой, и это продолжиться до тех пор пока месяц не истечет и тред исчезнет из топа...

>не путайте фасад который _выше_ бизнес-лейера и дата-лейер который _ниже_ бизнес-лейера

Фасад - это интерфейс бизнеслеера.

>если нет - то как же вы из презентейшн-лейера идентифицируете бизнес-объекты?

Вы когда в реальной жизни обсуждаете что-то вы как идентифицируете объекты? Первичными ключами?

>видимо есть в бизнес-модели какие то уникальные для каждого объекта аттрибуты

Ага. Правильно. Из бизнес модели. Те самые которые принято выставлять в случае вебсервиса.

>а дальше в найденом объекте уже есть первичный ключь.

Если вы все еще про меня - так нету. Вот нету суррогатных ключей. Сюрприз?

>. каким боком тут ОРМ чему то может мешать я чесно говоря не очень понимаю.

Очевидно вы забыли свое упоминание VO как варианта для решения данной задачи, коим описанная мной ситуация _не является_.

>бизнес-лейер создает ДТО соотвествующий бизнес-модели а не модели дата-лейера.

Это _не DTO_. DTO это конкретно описанный паттерн, а не любое возвращаемое значение, которое вам заблагорассудится.

>презентейшн видит бизнес-модель, а не модель дата-лейера.

НЕ могу не отметить тот факт что тут у вас уже отличается бизнес мождель и модель дата леера. Что уже не персистит ORM предметных областей, а таки имеет специально заточенную под RDBMS модель?

Перед тем как вступать в полемику - разрешите свое высказанное противоречие о различии бизнес-модели и дата-модели сами с собой.

>но они (синтетические первичные ключи) _есть_ в _имплементации_ этих интерфейсов.

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

>они не в спринге. они в нашем приложении.

Исходный посыл дал что IoC мне что-то там не даст и вообще. Что - уже даст?

>они не врут. вы просто не совсем поняли то что цитируете.

Вы мне заявили что я до чего-то там не доберусь из JSP, не получу оттуда доступ к модели, потому что некий "спринг" мне этого недаст потому что это не тру и должно вылезать из контролерера, на что я вам показал что я до всего доберусь и вообще до всего чего хочу доберусь. Шо неясно? Где непонятно?

>в спринге MVC построен поверх ИоК.

И что ? IoC знает про вьевы и контроллеры? Вы совсем из контекста вылетели.

>как правило можно но не нужно. а иногда - нельзя.

Вот е - повторяю по буквам, _з н а ч и т я М О Г У д о б р а т ь с я из JSP куда мне надо и препятствий этому нет?_ Все? Вопрос исчерпан? Поняли что сморозили глупость сказав что вьев не имеет доступ к модели и спринг мне не даст?

> вопросы были о том что "а ничего что из какого нибудь левого дизайнерского темплита фронтенда напрямую будет по ошибке неправильно вызван какой то достаточно деструктивный код бекенда?

Мля у меня нет слов: кто только что сказал "как правило можно "? Вы что осмыслить собственный ответ не можете?

>"а ничего что такой подход превращает темплиты в месиво из частей бизнес-кода и дизайна?

Кто вам такую глупость сказал?

>"а ничего что я из XSLT не имею возможности вызывать какой либо бизнес-код?"

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

>а тут скажу что все ваши аргументы ведут к тому что ЖСП это большая дыра в секюрности.

Это ппс полный. JSP это долбаный сервлет который крутится в том же класслоадере что и весь вебапп, является чистым джавовским классом имеющим доступ куда угодно. Никакой дырой он в секурности не является это часть приложения он не более дыра в секурности чем любой джавовский класс проекта. Хватит уже нести бред.

>представьте себе приложение где пользователи должны иметь возможность менять свои темплейты дизайна.

Мля - они JSP шки чтоли менять будут!? Если нет - какого хрена? Если да - то они и так сделают с вашей программой все что душе угодно потому что скриптлеты никто не запрещал. Что за бред - вы оказывается еще и не знаете какая часть JSP компилируется а какая исполняется в рантайме? Я хренею дорогая редакция.

>"спринг в вебе" легко дописывается нами так что становится несколько класслоадеров которые

Легко дописать _вы_ можете хоть ассемблерные вставки на Java - вперед. Сам спринг нихрена такого не делает. Завязывайте нести махровый бред и изучайте инструменты которыми пользуйтесь.

вы всё еще болеете? :))

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

к вашему возможному удивлению я знаю как из XSLT вызывать любой Java код. вот только мне не понятно зачем мне тогда нужен XSLT если мне еще придется вызывать из него Java код? теряется всякий смысл в использовании XSLT таким образом. начиная с того что XSLT становится непортабельным (например на C++ Xalan, Sablotron и тд и тп это уже работать не будет). Вы считаете это соотвествует предназначению XSLT ? XSLT создавался чтобы из него потом вызывали Java-код? XSLT создавался для того чтобы получить на вход SAX или DOM модель и выдать трансформированный результат.

>ля у меня нет слов: кто только что сказал "как правило можно "? Вы что осмыслить собственный ответ не можете?

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

вам наверное сейчас очень плохо да? извините.

>Это ппс полный. JSP это долбаный сервлет который крутится в том же класслоадере что и весь вебапп, является чистым джавовским классом имеющим доступ куда угодно. Никакой дырой он в секурности не является это часть приложения он не более дыра в секурности чем любой джавовский класс проекта. Хватит уже нести бред.

ЖСП это дыра в тех случаях когда какие либо "третьи лица" будут иметь возможность менять дизайн приложения посредством изменения этих самых JSP. представьте себе такие приложения бывают. когда у разных пользователей этого приложения есть личные шаблоны дизайна. правда как правило в этих случаях JSP не используется. по указанным выше проблемам с секюрностью.

>Мля - они JSP шки чтоли менять будут!? Если нет - какого хрена?

а нука раскажите как зачем нужны жсп? они нужны? зачем? в них легко что то менять? что легко в них менять? ась?

>Сам спринг нихрена такого не делает.

сам спринг просто создан чтобы так делать. не делает он это только потому что не все понимает зачем так делать. спринг - не интрузивный фреймворк. он дает возможность делать всё. в том числе и запрещать.

>Вы мне заявили что я до чего-то там не доберусь из JSP, не получу оттуда доступ к модели, потому что некий "спринг" мне этого недаст потому что это не тру и должно вылезать из контролерера, на что я вам показал что я до всего доберусь и вообще до всего чего хочу доберусь. Шо неясно? Где непонятно?

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