SolYUtorLord BritishДавайте все же вернемся к EF, UOW, REPO и потроллим друг-друга на тему надо/не надо.
К сожалению, в тему заглянули только штатные тролли, поэтому развести дискуссию по существу будет напряжённо. :)

Могу лишь изложить поподробнее своё мнение. Сам прошёл путь Stored Procedure -> NHibernate -> Repository over Nhibernate -> NHibernate -> NoSQL (в процессе).

В общем, в процессе работы по принципу Repository over Nhibernate пришёл к пониманию, что мне просто не хватает возможностей, которые есть в NH, и я потихоньку привожу Repository к ISesson. В итоге просто выкинул ненужным мне слой. И чуть позже наткнулся на хорошие блоги по этой теме: раз , два , и (особенно для любителей SOLID'а) три . Сам я тоже любитель SOLID. Но кроме него, надо держать в голове и свой разум. Ибо видел совершенно "солидный", но абсолютно неподдерживаемый код.

И вдогонку. Вся эта суета вокруг слоёв вообще, и репозитория в частности задумывалась ради одной цели - сделать код более поддерживаемым за счёт повышения его понятности. И еще повторного использования кода. На самом деле, обычно гораздо проще для поддерживаемсяости использовать не горизонтальное деление - слои, а вертикальное - разделы. При этом используя как можно меньше псевдоабстракций. С повторным использованием, всё еще проще - 90% кода повторно не используется. На практике это выглядит так: прямо в коде MVC-контроллера берём сессию, строим запрос, бросаме результат во ViewModel. Просто, понятно, быстро, тестируемо. Profit.

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

SolYUtorSeVa Nhibernate LazyLoading в многослойном приложении

Вот одна из типичных проблем при использовании всех ORM. Начинают лепить городухи для ленивой загрузки, а они рассчитаны только под чистый CRUD
Если в процессе забивания гвоздя бьёшь молотком по пальцу, в этом молоток виноват, да?

Бывают молотки, с которыми можно бить только себе по пальцам. Их нужно выбрасывать и все.

МСУSeVaЯ тебе миллион раз говорил, чтобы ты подтирался своей вики сам. Она только для этого пригодна. Я не собираюсь читать это и вникать в твою дурь.
Дурень, тебе вникать просто нечем, это проблема не википедии, это проблема твой тупости. Обосрался ты сегодня знатно, очередной раз опускаем тебя на форуме. Какого оно, быть унылой кухаркой, поведай нем?

SeVaЕсли не в контроллере, то где? В космосе, муфлон, она должна быть реализована? Во view и моdel ей не место
Дятел тупорылый, в моделе и только в моделе. Не в контроллере, не во вью, не во вьюмоделе, не в репозитории. А в моделе. Заруби себе на носу, двоешник.

Начинающий программист не делает различий между доменной логикой или бизнес-правилами(а'la: null, not null) и логикой приложения(бизнес логикой: отправить сообщение о поступлении оплаты, интеграция с внешними системами и тд).
Это две большие разницы. Или ты предлагаешь интеграцию с платежной системой засунуть в модель Payment?

Один уродец гадит, а второе дитятко эту каку в рот тащит.

МСУSeVaБывают молотки, с которыми можно бить только себе по пальцам. Их нужно выбрасывать и все.
Один из таких молотков ты, бестолочь.

SeVaНачинающий программист не делает различий между доменной логикой или бизнес-правилами(а'la: null, not null) и логикой приложения(бизнес логикой: отправить сообщение о поступлении оплаты, интеграция с внешними системами и тд).
Бездарь типа тебя не понимает, что предметная область в контроллере не пишется. Контроллер - тонкий Glue Layer, которому до бизнес-логики, как тебе до объектно-ориентированного программирования.

SeVaЭто две большие разницы. Или ты предлагаешь интеграцию с платежной системой засунуть в модель Payment?
Один уродец гадит, а второе дитятко эту каку в рот тащит.
Интеграция с платежной системой реализуется в предметной области - совокупность доменных объектов, один из которых - Payment . Шагом марш читать букварь, недоросль.

Ну-ну, давай-ка подробней, умник. Есть модель Payment и большая куча поставщиков для проведения оплат. Что будут делать в этом случае детки, которые кроме вики ничего не видели? Расскажи и повесели на ночь

МСУSeVaпропущено...


Ну-ну, давай-ка подробней, умник. Есть модель Payment и большая куча поставщиков для проведения оплат. Что будут делать в этом случае детки, которые кроме вики ничего не видели? Расскажи и повесели на ночь
Тупиздень, когда ты научишься думать. Создается новый конструктор, на входе которого будет подаваться Supplier, относительно которого будет поднотавливаться проводка. Причем тут контроллер?

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

Вернее, может, но только у мудаков, на которых ты ссылаешься

МСУSeVaпропущено...


Ну, муфел, теперь осталось сделать последние потуги и выяснить, что никакой логики взаимодействия с платежными системами в Payment быть не может.
Кухарка, ты сказала, что Payment это модель. Не путай божий дар с яичницей - дай угадаю, твоё скудное воображение «моделью» называет «дата-класс», предоставляющий абстракцию от БД? А теперь пшел вон читать букварь, в MVC модель - класс с бизнес логикой, никакого отношения к дата классу (EF, NH, L2S) не имеет. Опять двойка, садись.
Твоя детская задача даже второгодниками, а у тебя трудности.


Опять путаница в показаниях, чмошник. То у тебя Payment, то Provider, а теперь бредни с EF.
Что такое модель можешь писать статейки в русской вики , там твои бредни не будут выделяться на общем фоне.
И так внятно объясни, что где и как. Приплюсуй сюда еще отправку сообщения после оплаты.

МСУSeVaОпять путаница в показаниях, чмошник. То у тебя Payment, то Provider, а теперь бредни с EF.
Что такое модель можешь писать статейки в русской вики , там твои бредни не будут выделяться на общем фоне.
И так внятно объясни, что где и как. Приплюсуй сюда еще отправку сообщения после оплаты.
Чтобы что-то внятно объяснить унылой обезьяне, она должна обладать хоть малым представлением о уровене объектов предметной области. Учу неуча, классический MVP подход:
IDataProvider нужен для извлечения информации из БД (PaymentDb, PaymentDetailDb, PaymentTypeDb) и намапливания на DTO болванки (PaymentDTO)

Модель (Payment, а лучше назвать PaymentModel, чтобы не было путаницы с data-классами) взаимодействует с PaymentDTO и ISupplier и рассчитывает логику. new PaymentModel(ISupplier, PaymentDTO)

Контроллер тупо обращается к IDataProvider, инстанциирует PaymentModel и снимает расчет. Отправку данных по счетам или что там у тебя, реализуется точно так же в PaymentModel. Сам контроллер ни в коем случае не реализует бизнес логику, дурень.

P.S. Лишь в самых простых случаях некоторые идут на экономию (что-бы не плодить DTO) и пропихивают через контроллер в представление - сам data-класс (PaymentDb и иже). Впринципе, приемлемо для случаев, где особо никакой логики не нужно, кроме как вытащить данные из БД и отобразить их во вью.

RTFM: Model-View-Controller

Ты мне на вопрос ответишь? 13769830 Хочу еще поглумиться над идиотом.


Тупая обезьянка, где ты в MVP нашел контроллер? То, что ты описываешь, никакого отношения к этому паттерну не имеет.
И не скачи с ветки на ветку, ты утверждал, что вся бизнес-логика в МVС должна быть в Моdel. Опиши как этот бред будет выглядеть в этом случае. Забудь про свои DTO, EF и прочие мелочи, а то и так полный винегрет

МСУSeVa, ты ссылку читал?



Что не ясно из схемы? Контроллер через сервис (у меня это некий IDataService) взаимодействует с моделью (бизнес логика) и представлением, представление тупо берет из модели посчитанные данные и отрисовывает. Сходи в садик, там тебе дети разжуют.

Ну, хоты бы что-то внятное.
А теперь нарисуй диаграмму для такого Use case:

1.Провести оплату через провайдера.
2. Если оплата прошла успешно, то сопоставить ее с неоплаченными счетами. Если нет, то показать ошибку пользователю
3. Передать данные об оплате в 1С
4. Всем полностью оплаченным Счетам изменить статус на Оплачено.
5. Если есть полностью оплаченные Счета, то :
- произвести уведомление Менеджеров по e-mail
- запустить складской процесс по резервированию на складе
- etc
- etc

Где здесь бизнес-логика и как ты ее будешь реализовывать исключительно в Мodel? Процессов несколько, возможны ветвления кто и как будет проводить их оркестровку?