Здравствуйте, ryf, Вы писали:
TK>>Есть несколько готовых сравнений Castle Project and Spring.Net — Part II (правда, оно за 2005-й год и кое-что уже поменялось), Castle vs Spring.NET
ryf>А castle вообще развивается? посмотрел у них на сайте последний релиз от ноября 2006 года.
Есть changeLog с ежедневной активностью http://fisheye3.cenqua.com/changelog/castleproject что касается выхода релизов то, это больше вопрос религии... кто-то любит их делать раз в месяц, а кто-то по завершении каких либо больших прорывов...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Да, Spring.NET тоже рассматривал. Лично мне Spring показался каким-то монструозным и перегруженным лишними деталями. у Castle основной плюс — проста и расширяемость.
Да, у меня тоже сложилось похожее впечатление
TK>Есть несколько готовых сравнений Castle Project and Spring.Net — Part II (правда, оно за 2005-й год и кое-что уже поменялось),
Неплохое сравнение, правда, несколько смущает то, что его автор — главный разработчик Castle
Здравствуйте, Ivan Danilov, Вы писали:
ID>Чем это вредно? К примеру, в серверной части распределенного приложения, почему бы не организовать таким образом мапперы? Какие альтернативы?
я ваших слов не понимаю, но чем плохи глоб. переменные — сказать могу. вот к прмеру я пишу архиватор. можно сделать глобальные переменные для текущего архива, выполняемой команды, процесса выполгнения. работает вроде отлично. затем я делаю графическую оболочку, возможность выполнения азадний в бэграунде и "всё смешалось в доме Облонских". есть арзив, открытый в GUI, есть обрабатываемый одной bg командой, и другой. есть параллельно выполняемые процессы упаковки и распаковки (например, при обновлении солид архива) — а состояние у них одно на двоих? в общем, это мешает скалировать приложение, включать его как часть более общей системы, где таких объектов может потребоваться создать несколько
вторая проблема — если выполнение процедуры зависит не только от её параметров, то задачу труднее отлаживать, тестировать, больше вероятность того, что она "отвалится" от незначительных изменений типа изменения порядка вызовов или порпуска вызова в какой-то редкой ситуации
Здравствуйте, TK, Вы писали:
TK>Я бы посмотрел на готовые примеры/реализации — обычно, там уже есть и готовые примеры использования и описание тех или иных возможностей. Мне больше приглянулся http://www.castleproject.org/container/index.html как с наиболее человечный
Еще вопрос, больше технического плана: конструкторы сервисов, регистрируемых в Remoting, вызываются извне. То есть через параметры конструктора при помощи IoC-контейнера передать экземляры нужных ему контроллеров не выйдет. Как тут выкрутиться?
ID>Еще вопрос, больше технического плана: конструкторы сервисов, регистрируемых в Remoting, вызываются извне. То есть через параметры конструктора при помощи IoC-контейнера передать экземляры нужных ему контроллеров не выйдет. Как тут выкрутиться?
