омг, они еще и роботноги крутят к старлингу. суспендеры так и оставили там, тормоза на тормозах будут же. чем плохо использование сервисов через синглтон? иньекция ничем не лучше же.
github.com
1.5.2 таки уговорил меня оставить и не выпиливать его. Как не крути, но он организует архитектуру и местами упрощает. Но будущие проекты я вряд ли буду основывать на нем.
Я же напротив близок к тому моменту, когда нах выпилю робоноги из своего проекта. Он очень хорошь и я его тупо недостоин :)
1. Being able to access this API (SERVICE) directly can save your application from unnecessary command classes to achieve the same goal. — Типа инжектим Service в Mediator, и экономим на Command классах. 2.If the service API is repeatedly accessed in the same way from many mediators, it can be beneficial to encapsulate this behavior in a command to keep the behavior consistent and reduce the repetition of injecting the service and accessing it directly in your mediators. — Если Service нужен одинаково в нескольких медиаторах, то удобнее использовать для уведомления Servica класс Command. — Я предпочитаю второй путь, хоть и оба варианта дружат с decoupling.
Как предпочитаете в медиаторы получать данные от сервиса? Через аргумент события, которое отправляется из сервиса, или сначала данные отправляете в модель, а потом, по событию типа DATA_MODEL_READY — уже запрашивать в медиаторе из модели (например, инжектируя экземпляр класса модели в медиатор)? Или может быть есть какой-то более изящный путь?
Mate в борьбе с совпадением строковых констант событий, предлагал писать длиннннные строки для этих самых констант. Robotlegs пошел другим путем и предлогает кроме типа события (читай строки) передавать и ссылку на класс самого события.
Трудно даже выбрать какого варианта придерживаться. Mate вариант меня устраивает, т.к. можно опускать лишний параметр при подписке на событие, а robotlegs еще и во время выполнения проверяет.
Забыл сказать. Много модульное приложение работает :) Все заработало на ура, конфликтов не заметил, все в своих песочницах правда, но это и устраивает. Правда пришлось вручную запускать context в главном модуле, чтобы все погрузилось и расползлось по инъекциям. А так супер удобно
А как robotlegs ведет себя в случае модульного проекта, когда модули грузятся в общую applicationDomain и в модулях есть общие классы?
Хочу попробовать robotlegs на боевом проекте, ясное дело чистое as, а так бы взял mate.
Отговорите меня пока не поздно если я зря это задумал.
Some people prefer the Presentation pattern over the Mediator pattern. If you are new to frameworks/patterns I would suggest trying out the Mediator pattern — it's very easy to create spaghetti code with the Presentation pattern while you're still learning. knowledge.robotlegs.org
Скажите честно, смотреть или даже не стоит?
Robotlegs замечательный! Особенно в связке с сигналами joelhooks.com CompositeSignalCommand http://destroytoday.com/blog/2010/11/introducing-asyncsignalcommand-and-compositesignalcommand/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+destroytoday+(Destroy+Today)&utm_content=Google+Reader
Кто-нибудь пользовал robotlegs.org ? Стоит ли игра свечь?
Задача минимум на сегодня — перейти на maven и начать использовать robotlegs. Все на живом проекте, первые результаты которого надо показать сегодня где то часа через два ) А то с таким бешеным темпом разработок чувствую не изучу интересные мне технологии и практики — приходиться рисковать