SerP19832МСУ
Я не про orm, я про это Linq over WCF
Ну я понял, BLT Linq провайдер идет же в комплекте с этой ORM. Ну ладно, не суть.

Алексей КНу вот, опять... Вся логика крутится внутри одного сервера приложений. Про SOA я не говорил.
Ну так в случае веба там тоже репозиторий крутится на сервере приложений. Только лапшекод из бизнес методов вынесен в отдельную абстракцию. Это как гавнокодить логику в обработчике кнопки :)

Алексей КНу у меня WPF. Логика естественным образом отделяется от "морды" WCF-ом. :-)
А в аспнете да, там есть соблазн запихать всё в контроллер. :-)
Милок, а чем идеологически твой толстый ServiceContract отличается от контроллера в ASP.NET? :) Лично считаю утолщать эти классы - зло. Нужна дополнительная абстракция и называется она - репозиторий. Отдельная сборка, твой ServiceContract ничего не должен знать о БД.

Алексей КЭто я к тому, что в следствие имеющейся архитектуры, мне дополнительные абстракции в виде слоя репозитариев на сервере приложений не нужны. Если я правильно тебя понял, у меня сетевая служба сервера приложения является репозитарием.
Нужны, Леша, нужны. Не спорь, а верь мне на слово. Не зря я писал про ограждение неофитов от тебя :)



Не учи детей плохому!

Алексей КНакой мне слой методов, содержащих только делегирование?
Зачем же только делегирование? В контроллере ты можешь маппить dto и модели, писать условия в разрезе секурности, что-то анализировать и т.д. А потом вызывать честный репозиторий, передавать подготовленные аргументы, принимать результат, маппить его на dto, формировать текст и код ошибки, если она есть, и возвращать требуемый объект. Как видишь, контроллер (метод сервис контракта) это не тупо делегирование.

Алексей КМСУМилок, а чем идеологически твой толстый ServiceContract отличается от контроллера в ASP.NET? :)Тем, что в аспнет метод контроллера может содержать код, отвечающий за управление не только данными, но и View.
Ты заблуждаешься. В асп.нет контроллер ничего не знает о View, отдает только модель для представления. И тут тоже самое, по сути. Твой метод подготавливает ответ с конкретным DTO. На лицо аналогия.

Алексей КНу всё правильно, в аспнет - да. Но в WCF?
Да какая разница? :) Что метод контроллера, что метод webapi контроллера, что метод odata контроллера, что operation contract метод, что метод веб сервиса. Никакой принципиальной разницы. Все эти методы должны честно общаться с middle слоем, который и представляет собой репозиторий. Вот о чем тут спич трется.

Алексей КЯ привёл выше реальный пример. Там будет только делегирование + атрибуты для безопасности. Обработка ошибок у меня централизованная, вынесена в ServiceBehavior.
Ну для каких-то элементарных методов может и будет делегирование, но это как правило редкость. Во многих случаях те же ошибки, информацию о прохождении валидации и т.п. пакуют в ответ. И это более правильный подход на мой взгляд, чем жить в рутине try/catch.

Алексей КЗачем мне такое счастье?
Ты про свой лапшекод в "обработчиках", который прибит к конкретной БД? :)

http://msdn.microsoft.com/ru-ru/library/gg416511(v=vs.98).aspx Добавление репозитория
При работе с платформой MVC не рекомендуется включать модель сущность-данные (EDM) или код какой-либо другой платформы доступа к данным в контроллер. Вместо этого нужно использовать шаблон репозитория. Репозиторий располагается между приложением и хранилищем данных. Репозиторий разделяет бизнес-логику и взаимодействие с исходной базой данных и объединяет все операции доступа к данным в одной области, что значительно упрощает создание и обслуживание данных.
Репозиторий возвращает объекты из модели домена. В простых моделях, таких как та, которая используется в этом пошаговом руководстве, объекты, возвращаемые из EDM, LINQ to SQL и других моделей данных, квалифицируются как объекты домена.
В более сложных приложениях может потребоваться слой сопоставления. Слой сопоставления не всегда оказывается неэффективным. Поставщики LINQ могут создавать эффективные запросы серверному хранилищу данных (то есть они могут отправлять запросы с использованием минимального числа промежуточных объектов).
Для того чтобы использовать репозиторий, не требуются глубокие знания EDM, LINQ to SQL или каких-либо других моделей данных, с которыми работает пользователь. (Хотя LINQ не описывается в данном пошаговом руководстве, использование LINQ в качестве абстракции запросов означает, что механизм хранения данных можно скрыть. Благодаря этому можно, например, использовать SQL Server для производства, а LINQ to Objects в коллекциях в оперативной памяти — для тестирования.)
Чтобы протестировать методы действий в контроллере, осуществляющие прямой доступ к модели EDM, необходимо подключение к базе данных, поскольку методы действий зависят от EDM (которая, в свою очередь, зависит от базы данных). В следующем примере кода показан контроллер MVC, использующий сущность "Контакт" модели EDM напрямую. Кроме того, из этого примера становится понятно, почему смешение вызовов базы данных в методах действий усложняет тестирование метода действия. Например, модульные тесты, изменяющие и удаляющие данные, изменяют состояние базы данных. Поэтому для каждого прохождения модульного теста требуется чистая база данных. Кроме того, вызовы базы данных расходуют большое количество ресурсов, а модульные тесты — незначительное количество ресурсов, поэтому их можно часто выполнять в ходе разработки приложения.

Алексей КМСУТы заблуждаешься. В асп.нет контроллер ничего не знает о View, отдает только модель для представления.Ну он там может знать, а может и не знать. Например, в зависимости от каких-то условий вернуть разные вью. Но не буду спорить, я в аспнете пока не силён. :-)
Он не может знать о представлении. Без ну и но :)

Алексей Кв зависимости от каких-то условий вернуть разные вью.
Вернуть вью - это не знать он них :) Он может вернуть "название вью", а доступ к представлению запрещен по сути даже самого паттерна MVC.

Алексей КМСУВо многих случаях те же ошибки, информацию о прохождении валидации и т.п. пакуют в ответ. И это более правильный подход на мой взгляд, чем жить в рутине try/catch.Повторюсь, в WCF есть возможность централизовать обработку ошибок, написав соответствующий ServiceBehavior. В аспнете есть аналогичные возможности. Я же дал реальный пример, там нет ни одного try/catch.
Да не суть, есть возможность в wcf - и шут с ней. Я говорю о том, что нужно разделять бизнес-логику и взаимодействие с БД (или любым источником) + объединять все операции доступа к данным в одной области, что значительно упрощает создание и обслуживание данных . Вот основной момент. А как ты там обработаешь ошибку, второй момент.

Алексей КНу вот, это и есть логика управления представлением, о чём я и говорю. :-)
Это не "управление представлением" :)

Алексей КМСУпропущено...
Вот только не надо мне цитировать архитектурные советы гореархитекторов из Microsoft. Они в последнее время такого нагородили, что доверия к ним в ближайшие года не будет.
Жжешь.

Вынес в отдельный рецепт: Рекомендация MS об использовании репозитория в MVC
Оргаждаю неофитов... ))

Алексей КОсновной момент в том, что тут описано максимальное количество слоёв, которые можно реализовать в данной архитектуре.
Не максимальный, а минимальный. Можно добавить для более сложных случаев слой сопоставления . Описано в том же мануале от MS, который ты по непонятным причинам забраковал.

Алексей КА вот нужны ли они мне все в моём конкретном случае - это уже моё личное дело, и если я какие-то слои посчитаю ненужными в данном проекте - никто не в праве осуждать меня за это. У меня одна из целей - сократить размер программы. Как ни крути, это один из наиболее эффективных способов сократить время разработки.
Ну хочешь "гавнокодить в обработчиках" - твоё право. Но тема у нас - репозиторий, не забыл? :)
Напоминаю, я некоторые еще товарищи объяснили автору, что IQueryable в репозитории - это зло. И объяснили почему. Ты встрял и начал ругаться на нас. В чем смысл твоих высказываний тогда, если тебе репозитории не нуждны? :)

Алексей КСкорее плачу... Планета деградирует...
Пойду попью кофейку, буду много думать об этом.

Алексей К"Гавнокодить" можно в любом месте. Наличие дополнительного слоя автоматически не избавляет от "говнокода".
Так никто не заставляет от него избавляться, если тебе он так дорог. Речь идет о:
МСУЯ говорю о том, что нужно разделять бизнес-логику и взаимодействие с БД (или любым источником) + объединять все операции доступа к данным в одной области, что значительно упрощает создание и обслуживание данных.

Алексей КБолее того, "гавнокод" в нескольких слоях гораздо хуже "гавнокода" в одном слое.
Смотря с какой стороны посмотреть :)

Алексей КВсё правильно. Мы говорим об их нужности в различных условиях. :-)
Не ссать людям в глаза врать! Речь была о IQueryable в контроллере, за который ты так рьяно выступал
Не стыдно? :)

Алексей КПриятного аппетита. :-)
Спасибо :)

P.S. Какой итог? )