Решил проникнуться теорией и написать тестовый Bookstore. UI будет на WinForms, а затем ASP.Net MVC.

Открываю книжки / интернет и читаю что лучший вариант при создании приложения - это разделить приложение на слои.
Далее при построении UI на WinForms рекомендуют использовать паттерн MVP. Когда читаешь об MVP, то видешь пример, как люди ловкого его используют и для MVC. Когда читаешь об MVC, то не встретишь примеров использования MVP.

Так как первым UI будет WinForms, то решаю придерживаться паттерна MVP, а когда дойдет дело до MVC подумаю как прикрутить наработанное. ОК, все доводы в пользу слоев и MPV услышаны и приступаю к разработке.

Создаю 4 слоя Bookstore.DataLayer, Bookstore.BusinessLayer, Bookstore.WinForms, Bookstore.Mvc.

В DataLayer создержаться EF модели и контекст.

И тут возникают вопрос:
- куда запихнуть предпологаемые патерном MVP Model, View, Presenter. Все в бизнес слой?

Изопропилзапихнуть в задний проход
иди лесом ... неадекват.

PallarisАртем GСоздаю 4 слоя

Прежде чем что-то создавать, надо понимать, зачем это нужно, какая роль у каждого слоя, и что в нем будет находиться. Книжку почитай еще раз, плюс какие-нибудь статьи по отличиям MVP, MVC, MVVM, благо их навалом.

Книг и статей уже читано перечитано. Каша в голове. Пора перейти к практике. Я один. Старших товарищей рядом подсказать нет. Вариант один - это форум.

kmawАртем GДалее при построении UI на WinForms рекомендуют использовать паттерн MVP

не нужен

Тогда как правильно создать архитектру? на примере Bookstore с двумя интерфейсами.

skyANAАртем G, и ещё посмотрите на конкурентов: Amazone, Ozon, - у них микросервисная архитектура :)

Не смешно :) . Лушче б совет какой-нибудь дельный дали начинающему ).

hVostt,

Проект чисто устаканить то, что прочитано по Архитектектуре приложения. Оформить практическим заданием. Иначе от прочитанного ноль. Или не так?

Вот пример теории из книги.
Пользователь нажимет кнопку добавить товар > UI > Добавление товара> BusinessLogic > Сколько товара в наличии? > DataLayer > 0 товара в наличии > BusinessLogic > Этот товар не доступен > UI > Пользователь видет сообщение о недоступности товара.


Как я понимаю в моем примере с Bookstore первое что создасться справочник Книг. BusinessLogic будет содержать метод добавления книги в базу, проверку свойств на корректность.

den9000Презентер также отвечает за управление событиями пользовательского интерфейса (типа, MouseDown и т.п.), которое в MVC было заботой Представления. Т.е. все нужные события описываются в интерфейсе Представления и пробрасываются в Презентер, где и обрабатываются, что позволяет вынести из Представления логику их обработки.


Я правильно понимаю что между Presenter и BusinessLayer можно поставить знак равенства?

Блин опять читать :) Когда ж наступят светлые времена .... или они это и есть?
Почитаю .... надеюсь на просветление. Большое спасибо.

Алексей КАртем Gпропущено...


Я правильно понимаю что между Presenter и BusinessLayer можно поставить знак равенства?Нет, если:

прикладная логика != логика представления

ОК, понял.

PallarisАртем GЯ правильно понимаю что между Presenter и BusinessLayer можно поставить знак равенства?

Presenter и View - это UI-Layer.

Вот если взглянуть на код ниже тогда Model содержит бизнес логику?

RocknRollaАртем G Вот если взглянуть на код ниже тогда Model содержит бизнес логику?
Что содержит модель, Вам виднее.

А передача управления в данном случае корректна.

Если б было виднее не спрашивал бы. А код не мой а из книжки.

Вот полная цепочка от нажатия кнопки пользователем добавить товар в карзину до получения сообщения о недоступности
Пользователь нажимет кнопку добавить товар > UI > Добавление товара> BusinessLogic > Сколько товара в наличии? > DataLayer > 0 товара в наличии > BusinessLogic > Этот товар не доступен > UI > Пользователь видет сообщение о недоступности товара"

В этом примере видно что бизнес логика содержит
- метод Добавление товара,
- Функцию на проверку наличия товара,
- Отправку сообщения об недоступности товара,

в паттерне MPV эта логика в модели? передоваться во вью через Презентер? то есть бизнес логика в модели?

Pallaris,
Спасибо за ваши ответы. Одни из самых информативных.

Как итог:
Вопрос был
-где распределить предпологаемые патерном MVP Model, View, Presenter. Все в бизнес слой?

1.
PallarisPresenter и View - это UI-Layer.

2.
PallarisАртем Gбизнес логика в модели?
Хорошая модель должна содержать бизнес-логику, но без фанатизма. В данном конкретном случае я бы сделал на стороне слоя доменной модели некий сервис, который бы предоставлял данные о наличии товара, и дергал его из презентера.

ОК. Попробую создать приложение исходя из этого плюс спасибо RocknRolla. Параллельно почитаю про паттерны проектирования.

hVosttАртем GhVostt,

Проект чисто устаканить то, что прочитано по Архитектектуре приложения. Оформить практическим заданием. Иначе от прочитанного ноль. Или не так?

Вот пример теории из книги.
Пользователь нажимет кнопку добавить товар > UI > Добавление товара> BusinessLogic > Сколько товара в наличии? > DataLayer > 0 товара в наличии > BusinessLogic > Этот товар не доступен > UI > Пользователь видет сообщение о недоступности товара.


Как я понимаю в моем примере с Bookstore первое что создасться справочник Книг. BusinessLogic будет содержать метод добавления книги в базу, проверку свойств на корректность.

Предлагаю следующую методу. Возьми свой пример, и попробуй написать его так, как если бы сроки горели (ну ограничь себя, например, неделей), т.е. как-нибудь без слоёв и архитектурных паттернов, чтобы проект работал и выполнял 100% функций.

Затем начни обстоятельно исследовать свой проект с точки зрения архитекутуры, что бы ты и куда вынес и почему. Т.е. необходимо не просто следование какой-то заданной модели, а понимание — почему она именно такая, и что это даёт.

Иначе есть риск, что ты повозишься с этой мудотнёй, и решишь, что по-старинке (типа «вообще не парясь») работать как-то лучше и удобней. У каждой архитектуры есть своё предназначение, в зависимости от того, какие задачи решаются и как они должны решаться, архитектура может сильно отличаться. Нет какой-то стандартной модели слоёв, рассматривать их как примеры в вакууме (т.е. в отрыве от контекста применения) — как-то бессмысленно.

для того чтобы рассказать зачем мне это нужно мне придеться вдаваться во внутрикомпанейские детали... не очень хочется. тема об архитектуре, а внутрикомпанейские детали увидут разговор в сторону.

Сейчас на руках ~100 проектов разной сложности (как пример больше половина завязаны на сап: где то biz talk adapter, a где то sap script) от 4х различных "разработчиков", которые об архитектуре ни когда не думали а о паттернах ни когда не слышали. Все это добро теперь у меня на поддержке + нужно будет писать что-то новое. У самого с 10ок средней руки проектов, ни как не маштабируемы.

По этому когда я предложил для примера Bookstore - это только для того, чтобы не вдаваться в какие-то специфичные проекты, а обсудить тему на чем-то для всех знакомом.

hVosttТак что паттерны нужны и важны. А кто отрицает этот факт, тот просто находится на уровне таджика-индуса, о чём там вообще говорить? Ну устроился когда-то, сидит на своём проекте в одиночку — молодец, что ещё сказать. Но это единичные упоротые случаи сказочного везения. Так делать неправильно и нельзя.

Я чтение про паттерны проектирования / принцыпы проектирования нашел для себя полезным. Каждому начинающему желательно прочесть про них сразу после справочной информации по языку.

kmawАртем GСейчас на руках ~100 проектов
тут 0 не лишний?
Нет не лишний. Это количество того, что уже создано. Есть еще список в два раза больше опять же приблизительно что требует бизнес создать. Создать отчеты из сапа или наоборот сделать проводки в сапе стоят денег, плюс нехватка кадров. Вопрос решается локальными приложениями.

skyANAАртем G, ответьте для себя на вопрос: Как разнесение на такие вот слои поможет мне решить проблему масштабирования?
Конкретно разнесение по слоям не даст маштабируемость. И тут вопрос то есть вы советуете этого не делать?