Здравствуйте, Doc, Вы писали:
IT>>Что значит отдувался? Я пишу всю логику в контроллерах и ни секунды не сомневаюсь, что это правильно. Doc>Ну вот дошли до Fat Controllers. И эти люди говорят что я не понимаю MVC Doc>Кстати, Controller это у вас выходит BL?
Не нужно слова собеседника доводить до абсурда, а потом радостно заявлять "Ага!".
Мне сложно говорить за Игоря, но я 100% уверен, что в случае FatController-a, большая часть логики переедет из контроллера в другие классы/методы. И не столько важно в какую часть приложения уедет эта логика. Важно то, что при грамотной архитектуре (тут я имею ввиду "грамотной инфраструктуре" (например вынос валидации из контроллера)) и грамотной организации Юзер Сценариев (каждый "экран" делет необходимый минимум работы), необходимость в вынесении логики из котроллера куда-нить возникает редко.
Вы же, выделяя отдельный слой для BL, изначально обрекаете контроллер на функции "мальчика на побегушках", единственные обязанности которого бегать к BL и спрашивать "пользователь нажал кнопку, что делать?????".
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Doc, Вы писали:
A>Мне сложно говорить за Игоря, но я 100% уверен ...
Да почему всё за него говорят то То "UI в BL" и за него начинают утверждать что он совсем не то имел ввиду. Теперь и тут он не то оказывает сказал.
A>Вы же, выделяя отдельный слой для BL, изначально обрекаете контроллер на функции "мальчика на побегушках", единственные обязанности которого бегать к BL и спрашивать "пользователь нажал кнопку, что делать?????".
Так это и есть задача Controller — связать User Input и BL. Команды "думать" ему не было
Вот сейчас, похоже к радости Игоря , скажу что повторно используется BL в рамках одного Solution.
Поэтому у меня например BL как правило отдельная сборка. И её использует не только MyProject.WebUI, но и ряд других проектов (например сборщика данных) в этом же Solution (извините за bold).
Здравствуйте, Aikin, Вы писали:
A>Начинаем все сначала. Смысл в QO которое содержит только Linq выражение? ИХМО, чтобы QO имело смысл, нужно несколько реализаций под разные хранилища. Поэтому и сложнее.
Это при условии что они сразу используются в проекте. Кстати и вашем случае тогда будет куча разных запросов.
В большинстве случаев в текущий момент времени у нас конкретно хранилище. В этом случае QO помогают повторно использовать в BL одни и те же запросы. Я надеюсь что и вы свои linq выражения где-то в методах держите, а не через copy/paste по коду кидаете. Ну и переезд в этом случае на другой тип хранилища не трогает BL.
Отмечу, что сама "обертка для ORM" уже давно живет в своей библиотеке на локальном NuGet и в проектах пишу только сами QO или Spec (от задач проекта).
A>А какие варианты? Выбор конкретной реализации всегда в рантайме происходит. Если провайдеров больше одного, конечно.
См. выше. Для рантайма и с linq будет не меньшая заморочка. А для варианта "1 тип" можно подключить библиотеку с нужными QO и заменить её при необходимости.
A>А, так у вас еще и юнит тесты есть на всю логику. И интэгрэйшен сервер настроен. Так?
На BL да. Не 100% покрыто, но где-то 70% в среднем. Чем это плохо?
A>Я говорю за практику. Вы, похоже, о теории.
Да, да.. я помню о пузомерке... формулы расчета длинны пуза от достижений уже готовы?
Здравствуйте, Doc, Вы писали:
Doc>Я надеюсь что и вы свои linq выражения где-то в методах держите, а не через copy/paste по коду кидаете. Doc>Да, да.. я помню о пузомерке... формулы расчета длинны пуза от достижений уже готовы?
Давайте разойдемся. Как-то я устал от общения.
Здравствуйте, Doc, Вы писали:
IT>>Какие именно? Access, SQLite и SqlCe поддерживают. Embedded Firebird не пробовал, но наверняка тоже поддерживает. Doc>У меня SqlCe падала на попытке использовать транзакции с Exception что не поддерживается.
Что такое транзакции с Exception?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Aikin, Вы писали:
A>Не нужно слова собеседника доводить до абсурда, а потом радостно заявлять "Ага!".
Да ещё и делать это так неумело.
A>Мне сложно говорить за Игоря, но я 100% уверен, что в случае FatController-a, большая часть логики переедет из контроллера в другие классы/методы.
В слове FatController ключевое слово — Fat. И это означает, что у нас просто много функционала в одном месте. Если этот функционал переместить в BL, то мы получим FatBL. Вот и вся разница.
A>Вы же, выделяя отдельный слой для BL, изначально обрекаете контроллер на функции "мальчика на побегушках", единственные обязанности которого бегать к BL и спрашивать "пользователь нажал кнопку, что делать?????".
Не трать патроны. Это бесполезно. Товарищ упёрся в свои догмы и уже давно дискутирует по принциау "имею мнение хрен оспоришь".
Если нам не помогут, то мы тоже никого не пощадим.
Да, я тоже пришел к этому мнению. Самоустраняюсь
IT>В слове FatController ключевое слово — Fat. И это означает, что у нас просто много функционала в одном месте. Если этот функционал переместить в BL, то мы получим FatBL. Вот и вся разница.
Здравствуйте, IT, Вы писали:
IT>В слове FatController ключевое слово — Fat. И это означает, что у нас просто много функционала в одном месте. Если этот функционал переместить в BL, то мы получим FatBL.
Здравствуйте, Doc, Вы писали:
IT>>У меня в BLToolkit около полутора тысяч тестов с SqlCe и почти все с транзакциями. Doc>Хм. А они там через SQL команды заданы?
Через метод BeginTransaction.
Если нам не помогут, то мы тоже никого не пощадим.
То "UI в BL" и за него начинают утверждать что он совсем не то имел ввиду. Теперь и тут он не то оказывает сказал. 
Если нам не помогут, то мы тоже никого не пощадим.
