Linq to SQL слои / архитектура?

Question

Прошу прощения за мой вопрос, возможно, смотрю старые повторяющиеся вопросы, но я, когда я запускаю Linq to SQL, я хочу обсудить, сколько слоев (архитектуры) мне следует использовать?веб-сайты и малые и средние веб-приложения.Я понимаю, что разделение приложения на слои помогает поддерживать его и улучшать, но, честно говоря, я хочу некоторого баланса, который дал бы мне быструю разработку и возможность повторного использования кода.Я не могу тратить столько времени на нежелательное управление слоями.

До того, как я использовал 4 слоя (бизнес-объекты, BLL, DAL и пользовательский интерфейс). Я запутался в этом, поскольку разные люди описывали разные уровни.Скажите, пожалуйста, что и сколько слоев мне следует использовать?Спасибо

Answer 1

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

С учетом сказанного я обнаружил, что использование шаблона репозитория весьма полезно при работе с проектами LINQ to SQL. Я связываю это с шаблоном Model View Presenter (для веб-форм или других проектов), и он обеспечивает отличную основу для повторного использования с минимальными слоями.

Моя веб-форма вызывает класс Presenter, который, в свою очередь, отвечает за заполнение представления. Чтобы заполнить это представление, докладчик может вызвать N номеров репозиториев. Репозиторий - это место, где вы инкапсулируете свой класс DataContext и ваши вызовы LINQ to SQL. Эти вызовы возвращают классы модели.

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

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

Удачи!

Answer 2

Самым важным аспектом с точки зрения архитектуры является разделение интересов. Разделение проблем приводит к чистому коду, простоте обслуживания, расширяемости и т. Д. При этом я рекомендую основывать ваши решения на следующих критериях:

• Попытайтесь спроектировать вашу систему в слабосвязанной форме. Используйте обмен сообщениями вместо RPC, поскольку обмен сообщениями является надежным, масштабируемым, асинхронным, слабо связанным и т. Д. Вы можете использовать MSMQ или NServiceBus (для архитектуры на основе служебной шины).
• Создание слоев на основе концепции разделения интересов. Например, Вы можете выбрать типичную трехуровневую архитектуру, которая будет иметь только уровень пользовательского интерфейса, уровень бизнес-логики (бизнес-правила + рабочий процесс) и уровень доступа к данным или более детальный, такой как уровень пользовательского интерфейса, уровень служб (фасад), уровень бизнес-логики, уровень доступа к данным и т. д. Использование IoC / Dependency инъекций облегчит жизнь, поскольку ни один из слоев не будет иметь прямой зависимости. Более того, он упрощает модульное тестирование, поскольку вы внедряете макеты вместо реальных реализаций для модульного теста. Доступно так много платформ IoC (NInject, Autofac, Castle Windsor, Structure Map и т. Д.) *
• Попробуйте использовать EF вместо Linq to SQL, так как последний работает только с SQL, тогда как EF работает с любой базой данных. Более того, по моему мнению, EF - это то, где Microsoft занимается инновациями, и я бы предположил, что Linq to SQL может быть удален однажды.

Answer 3

Не используйте архитектуру слоя.Используйте луковую архитектуру .

Answer 4

Я решил использовать один слой (DAL + BLL) для небольших проектов, а для больших приложений - разные слои для DAL & BLL. Я буду использовать Linq в DAL, и funtiosn вернет IQueryable.