Я недавно ознакомился с трудом Seemann Mark под названием Dependency Injection in .NET. Не знаю какой вес имеет данный автор в мире .net но меня удивил тот факт что он прямо таки приравнял Service Locator к анти-паттернам. Признаюсь я использую в моих проектах юнити в купе с паттерном Service Locator но как-то не совсем представляю как обойтись без оного или чем заменить. В своих примерах автор часто создает экземпляр контейнера, для объяснения это подходит но для реал-ворлд приложения не очень. Что скажет автор по данному поводу? Спасибо
Ну насколько я помну там вопрос стоял ребром, в 7рку не включили а восмерку планировали через год макс и поползли слухи что в связи с плотным графиком возможно… И тогда видимо народ взбунтовался и решили дату выхода 8 версии сдвинуть. Может я конечно ошибаюсь и это только слухи но изменение даты выхода имело место.
В play 1.* нет никакой поддержки dao весь автоматизм реализован для поддержки activerecord паттерна. Далее вы говорите про включение поддержки дао, я не знаю каким способом вы ее включаете но изначально play не предусматривает ничего такого. Вам приходися или все делать руками или же использовать готовый модуль.
Спасибо за информацию, но согласитесь что до последнего момента не было уверености что замыкания войдут в состав 8 версии и х как то уж усиленно двигали в сторону 9. Кстати не замыкания ли виноваты в сдвиге даты выхода 8 версии по сравнению с объявленными датами сразу после покупки java ораклом?
Насчет фич в моно есть все необходимое и за ним стоит солидная контора а уровень поддержки нисколько не отличается от j2se. Когда я говорю про склеивание ласт я имею ввиду только java как язык. Одерский как то сказал в одной из своих заметок что java который мы знаем уже давно исчерпал свои возможности а вот jvm нет и именно с ней и стоит работать и развивать ее. Например еклипс как всегда обгадился делая ставку на язык поверх java вместо jvm.
Дык на кобыле (cobol) тоже вон сколько всего написанно. А что собственно вам мешает Hadoop, Lucene итд портировать на c# получится гороздо лучше. Склеивание ласт начинается с забрасывания обогащения фич языка. А то что весь энтерпрайз сидит то заслуги прошлых лет и только sun и если ничего не предринять то будет поздно.
Плей как раз и не был задуман для работы с dao он предусматривал работу а ля рор с актив рекордом, а уш что там всякие доморощенные умелцы накрутили своими кривыми руками с dao то это на их и собственно ваш страх и риск.
Да а вы пробовали веб сокеты хостит на грейлз, он не чуть не легковеснее спринга, скорее наоборот. Оба этих продукта работают только с контейнерами сервлетов, что вас отбрасывает на столетия назад к комете и плохому симулированию асинхронизма. Для малых и простых проектов это некритично.
Согласен с вами, на мой взгляд с java дела обстоят точно так же как с cobol который до сих пор можно встретить во многих организациях например в крупных банках Люксембурга. Платформа будет существовать еще достаточно долго, наверное столько сколько будет спрос даже если большенство разработчиков будут отдавать предпочтения другим языкам.
Да сравнинте хотя бы фичи по датам выпуска в c# и java, там разница в несколько световых лет. Например если говорить про консервативный с++ до даже в его последнем стандарте есть поддержка closure а в java такая фича еще до сих пор под вопросом. Да это сугубо мое личное мение, может от части схожее с авторским. Если вы хотите тут развести троллоло то не советую.
Немного о политике. Если версия 2.0 курировалась и писалась в zenexity людьми очарованными haskell, f# и scala и которые не могли смотреть на java без рвотных позывов, то версия 2.1 дорабатывалась typesafe так как zenexity не выполнила своих прямых обязательств в срок. Сложно сказать будет ли в play 2.* нормальная поддержка java как в 1.*. Насколько мне известно typesafe определили на проект play именно scala разработчиков, да компания продвигает именно scala на рынке. Скорее всего поддержка java будет болтаться в проруби и в последующих версиях. С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.
На самом деле это более тривиально. Когда-то давно поработала программа-конвертер диаграмм uml в конечные интерфейсы пользователя. Власть имущие видимо влюбились в данный продукт (стоимость которого включает много нулей) ну и потом использовали его повсеместно, далее управленцы пошли на повышение, ну а сорцы сгенерированные данной прелестью стали дополнятся разработчиками и очутились, CVS и использовались в продакшене достаточно долгое время, такое вот брожение.
Мне кажется это интернациональная проблема, как знаете говорят что дураков везде хватает. Но вот по странным обстоятельствам их всех тянет в финансовую сферу. Мы как то проводили аудит для lcl.fr дак я там такого насмотрелся. Типа совершено непонятные классы которые делали непонятно что
public class X2458_chaîne_4857_698544 : XBase_chaîne_5486_6987 { /* hairy code */ }
А проблемы у них были из за того что пользователи интернет банка могли видеть чужие счета время от времени. И пришлось им сотрудничать с нами долго для доведения до ума их системы.
Ох ну наконец-то хоть одна статья без лоббирования кетайфонов (я так понимаю данный телефон собран не в кетайе). Благослови вас Господь, спасибо за обзор.
Не забывайте что в случае с ФФ и с Хромиумом с каждым выпуском прибавляются и багфиксы и исправления критических дыр безопасности. Встраивание браузера это конечно хорошо но не для критических приложений. Там еще есть одна большая проблема все движки браузеров поддерживают пока только х32 архитектуру есть найт билды под х64 но они остаются найтами.
Право не знаю из какого нафталина вы достали скайбоунд и geckofx с гуглкода. А глядя на ваши муки с ними аж слезы наворачиваются. Оба этих проекта мертвы, сударь. А вот их логическое продолжение — bitbucket.org/geckofx/geckofx-18.0 они выходят примерно след в след за новыми версиями firefox/xulrunner. Проект живой и там есть и поддержка winforms для любителей античности и wpf для любителей ретро.
Awesomium так себе, у него даже лицензия вражеская. А ведь есть такие проекты как Xilium.CefGlue (его уже упоминали).
Я недавно ознакомился с трудом Seemann Mark под названием Dependency Injection in .NET. Не знаю какой вес имеет данный автор в мире .net но меня удивил тот факт что он прямо таки приравнял Service Locator к анти-паттернам. Признаюсь я использую в моих проектах юнити в купе с паттерном Service Locator но как-то не совсем представляю как обойтись без оного или чем заменить. В своих примерах автор часто создает экземпляр контейнера, для объяснения это подходит но для реал-ворлд приложения не очень. Что скажет автор по данному поводу? Спасибо
А проблемы у них были из за того что пользователи интернет банка могли видеть чужие счета время от времени. И пришлось им сотрудничать с нами долго для доведения до ума их системы.
Awesomium так себе, у него даже лицензия вражеская. А ведь есть такие проекты как Xilium.CefGlue (его уже упоминали).