Как бы вы организовали это в asp.net mvc?

Question

У меня есть приложение asp.net mvc 2.0, которое содержит области / модули, такие как календарь, администратор и т. Д. ... Могут быть случаи, когда более чем одной области требуется доступ к одному и тому же репо, поэтому я не уверен, куда поместить уровни доступа к данным и репозитории.

Первый вариант: Должен ли я создавать файлы уровня доступа к данным (в моем случае Linq to SQL) с соответствующими репозиториями для каждой области, поэтому каждая область содержит только таблицы и репозитории, необходимые для этих областей.

Преимущество состоит в том, что все, что нужно для запуска этого модуля, - это одно место, поэтому оно более инкапсулировано (в любом случае, на мой взгляд). Недостатком является то, что у меня могут быть повторяющиеся запросы, потому что другие модули могут использовать тот же запрос.

Второй вариант Или было бы лучше разместить DAL и хранилища за пределами Района и рассматривать их как глобальные?

Преимущество в том, что у меня не будет повторяющихся запросов, но я могу загружать много ненужных запросов и таблиц DAL для определенных модулей. Это также больше работы, чтобы повторно использовать или модифицировать эти модули для будущих проектов (хотя вероятность их повторного использования невелика:))

Какой вариант имеет больше смысла? Если у кого-то есть способ получше, я бы хотел это услышать.

Спасибо!

Answer 1

Я бы переместил их в их собственную библиотеку сборок / классов и создал бы репозитории на основе "агрегатов". Это означает, что нужно создать репозиторий и DataContext для всех операций, которые имеют общую цель (например, публикации, комментарии, теги и т. Д.).

Это поможет отделить то, что должен делать каждый DataContext, и минимизировать отслеживание, которое DataContext делает за кулисами.

Кроме того, я не уверен, что вы имеете в виду, «но я могу загружать много ненужных запросов и таблиц DAL для определенных модулей». Если вы отслеживаете SQL, который создает Linq, вы можете довольно легко настроить свои запросы. Создайте открытые методы в своих репозиториях, которые возвращают только соответствующее количество записей из соответствующих таблиц. Вы будете удивлены, насколько эффективно вы можете получить SQL с Linq, минимизирующим «ненужные запросы».