четверг, 29 мая 2008 г.
воскресенье, 25 мая 2008 г.
SOA как панацея
В последнее время на каждом шагу слышу про SOA. Из нее делают просто таки панацею. А так ли это?
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что SOA становится модным словечком ... каким недавно был (да и остается по сей день) термин Web 2.0 или AJAX.
Если так дальше пойдет, то SOA будут запихивать везде и повсюду - как в свое время повсюду запихивали AJAX где надо и где не надо.
На мой взгляд, особую ценность представляет логика работы с данными и сами данные.
При построении архитектуры выстраивали трехзвенную архитектуру, например, data-view-controller.
А что если при построении систем строить объектную модель для работы с данными и объектную модель для бизнес логики которая ее использует. С помощью такого подхода можно менять хранилища данных по своему усмотрению, не меняя объектной модели - стоит только реализовать некоторый интерфейс по "доставанию" данных. При изменении же бизнес логики стоит только пересобрать отдельный слой - данные останутся прежними.
Если меняются структура данных - нужно изменить только слой работы с данными (тут конечно вопрос - надо ли при этом менять бизнес логику относительно изменения данных, но при нормальном оперировании объектами это будет необходимо достаточно редко).
Возможно, высказанные идеи не новы, но это то что навеяно проектированием. Я не борюсь за оригинальность.
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что SOA становится модным словечком ... каким недавно был (да и остается по сей день) термин Web 2.0 или AJAX.
Если так дальше пойдет, то SOA будут запихивать везде и повсюду - как в свое время повсюду запихивали AJAX где надо и где не надо.
На мой взгляд, особую ценность представляет логика работы с данными и сами данные.
При построении архитектуры выстраивали трехзвенную архитектуру, например, data-view-controller.
А что если при построении систем строить объектную модель для работы с данными и объектную модель для бизнес логики которая ее использует. С помощью такого подхода можно менять хранилища данных по своему усмотрению, не меняя объектной модели - стоит только реализовать некоторый интерфейс по "доставанию" данных. При изменении же бизнес логики стоит только пересобрать отдельный слой - данные останутся прежними.
Если меняются структура данных - нужно изменить только слой работы с данными (тут конечно вопрос - надо ли при этом менять бизнес логику относительно изменения данных, но при нормальном оперировании объектами это будет необходимо достаточно редко).
Возможно, высказанные идеи не новы, но это то что навеяно проектированием. Я не борюсь за оригинальность.
понедельник, 5 мая 2008 г.
Как прокладывать пешеходные дорожки
Однажды всплыла на обсуждение в отделе тема необходимости написания универсального кода. Сразу в голове сработала ассоциация с рассказанным мне однажды ,уже не помню кем, примером, как прокладывают пешеходные дорожки у нас и в Европе.
И так, как это делается у нас:
Архитектор при проектировании нового сооружения (дома, магазина и т.д.) продумывает (если продумывает) как будет выглядеть окружающая "обстановка" - детская площадка, стоянка и совместно с этим проектирует (порой непонятно чем, руководствуясь) дорожки для пешеходов. При этом никто не спрашивает пешеходов о том, будет ли им это удобно (да они собственно и не скажут - дорожек то еще нет - проверить не на чем). После того как сооружение построено, дорожки проложены, "поля засеяны" газоном - пешеходы начинают по этим газонам ходить так, как им это удобно, вытаптывая все на своем пути. Коммунальщики при этом, пытаясь сохранить приемлемый вид газонов, начинают "конструировать" всевозможные оградительные сооружения. В итоге страдают все (собственно как всегда у нас).Как делают на западе:
При сооружении ничего не планируют. Засеивают все пространство газоном и пускают пешеходов. Через полгода – год протаптываются аккуратные тропинки, по которым чаще всего ходят люди – их собственно и асфальтируют.Теперь сделаем некоторые выводы применительно к разработке:
- Если есть две зависимые разработки - делать их параллельно. При распараллеливании выявляем на этапе разработки потребности и тут же их решаем (если понадобиться повторное использование кода - всегда можно вынести уже реализованную логику).
- Не делать универсальных методов - исходить из потребностей. Так же проектировать разработку - исходя из потребностей.
- Хорошо анализировать потребности. Не надеяться что "это возможно в будущем где то понадобиться еще". Через месяц об повторном использовании кода может никто и не вспомнит и напишет свою логику.
Подписаться на:
Сообщения (Atom)