Торговая система своими руками. Часть 1. Введение. MVP.

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

   Даже такие проекты, как торговая система, требуют определённого подхода к структуре – проект разрастается со временем, хочется большего, и на это надо закладываться в самом начале. Даже, если система пишется под себя, не стоит уклоняться от  более формального подхода. Это, как ставить кубик на кубик — хорошая расстановка даст более прочную башню. Такие проекты справляются с увеличением сложности, новые изменения усиливают проект, в конце концов, такие проекты, способны перерасти во что-то более сложное (типа фазового перехода). А проекты с непродуманной архитектурой наоборот – со временем вносить изменения становится мучительнее и дороже, возрастают затраты на обслуживание, новые изменения ослабляют проект и он не способен перерасти во что-то более сложное. Но, сами понимаете, не всё так просто. Выбирая, каким будет проект, мы, опираясь на опыт, всё равно, угадываем направления развития.

   В программировании мало универсальных подходов, которые бы одинаково эффективно работали везде, и MVP (model-view-presenter) – это лишь один из шаблонов. Зачастую, в больших проектах разные шаблоны и принципы совмещаются. Назначение MVP простое – разнести ответственность по разным частям кода, и сделать структуру проекта наглядной и (что также очень важно) тестируемой.

   Обычно MVP интерпретируют,  как луковицу – это несколько независимых друг от друга слоёв. Model – это центральная часть системы, в ней зашита бизнес-логика и состояние, это сама суть системы, её уникальные свойства, то, что отличает одну систему от другой. Всё остальное – связь с БД, различные сервисы, периферия, формы – это детали реализации, от которых модель не должна зависеть.

   View или представление – это отображение: web-интерфейс, формы, или даже консоль. Всё то, благодаря чему мы можем взаимодействовать с моделью. Начинающие программисты обычно не разделяют model и view, а запихивают логику в события нажатия кнопок, или в события открытия форм. Это плохо тем, что со временем структура становится монолитной, не масштабируемой, не поддающейся изменениям. В такой структуре нельзя выделить какую-то часть и безболезненно изменить её – изменения в одной части, фиг знает как, отразятся на остальных.

   Модель не должна знать, что там, и как отображается. И Presenter (в 80x это называли Controller, тогда речь шла об устройствах ввода/вывода) – это как раз посредник,  коммутатор, соединяющий различные сервисы и модель, открывающий формы, и передающий данные между различными слоями программы.

Также, важно сказать, что такое Interface – это некая спецификация, на основе которой, можно построить реализацию – класс. Например, приходя в банк, я не иду к конкретной операционистке Танечке, мне не важно, кто это, я лишь хочу осуществить типовую операцию, прописанную в спецификации сотрудника – например, выдать деньги, или погасить кредит. Лучше не зависеть от реализации – она может поменяться (Танечка уйдёт в декрет), а зависеть от абстракции – интерфейса. Во всех частях программы я оперирую интерфейсами, а не конкретными реализациями. Где-то в самом начале программы, используя IoC контейнер, я описываю, какой класс реализует тот или иной интерфейс, но об этом позже.

   И ещё, скажу о событийно-ориентированном подходе – тут всё просто – есть оповещатель события и подписчики. Например, я попрошу приятеля позвонить мне, когда будут интересующие меня новости – я подписался на это событие, и я буду оповещён, когда оно произойдёт. В C# есть event’s (события), в определённый момент событие срабатывает, вызывая по очереди код на него подписавшийся. Так, например, устроены обработчики событий в компонентах форм.

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