Лучшие практики проектирования для архитектуры .NET с LINQ to SQL (необходим DAL? Можем ли мы действительно использовать POCO? Шаблон проектирования для принятия?)

Question

Я избегал писать то, что может показаться другим потоком в архитектуре .net arch / n-tier, но терпите меня.

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

Полагаю, я ищу мнение широкого сообщества о направлении и архитектурной реализации , которую вы выберете при создании корпоративного приложения, использующего большинство аспектов современной технологии .NET, и какое направление вы выберете. Я лучше расскажу о себе и своем вопросе, опасаясь, что это будет слишком расплывчато; Я хотел бы улучшить свою архитектуру для улучшения и очень хотел бы услышать, что вы, ребята, думаете, учитывая список технологий, которые я собираюсь написать.

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

Вот список технологий, принятых в моем последнем проекте, да почти все, кроме WPF:)

• Smart Client (WinForms)
• WCF
  • Используется Smart Client
• ASP.NET MVC
  • Инструмент администратора
  • Клиентский инструмент
• LINQ to SQL
  • Используется WCF
  • Используется ASP.NET MVC
• Microsoft SQL Server 2008

Утилиты и дополнительные компоненты для рассмотрения:

• Внедрение зависимостей - StructureMap
• Управление исключениями - Пользовательский
• Модульное тестирование - MBUnit

В настоящее время это работает в арке n-уровня. Приняв шаблон проектирования , основанный на сервисах, использующий запрос / ответ (не уверен, что его формальное имя) и шаблон репозитория, большая часть моей структуры была взята из Витрина Роба Конери .

Полагаю, я более или менее доволен большинством своих уровней (на самом деле это просто DAL, на котором я немного обеспокоен).

Прежде чем я закончу, вот реальные вопросы, с которыми я столкнулся в своей текущей архитектуре:

• У меня большой вопрос о том, должен ли я иметь пользовательский слой доступа к данным с использованием LINQ to SQL. Должен ли я выполнять LINQ to SQL непосредственно на моем сервисном / бизнес-уровне или в DAL методом репозитория? Должны ли вы создавать новый экземпляр контекста БД в каждом вызове метода репозитория (используя using ())? или один в конструкторе класса / через DI?

• Верите ли вы, что мы действительно можем использовать POCO (простые старые объекты CLR) при использовании LINQ to SQL? Мне бы очень хотелось увидеть некоторые примеры, так как я столкнулся с проблемами, и это было бы особенно удобно при работе с WCF, поскольку я, очевидно, не могу переносить объекты L2S по проводам.

• Создание проекта ASP.NET MVC само по себе довольно четко отображает шаблон проектирования, который вы должны принять, сохраняя логику представления в представлении, контроллер, вызывающий сервисные / бизнес-методы, и, конечно, ваш доступ к данным в модели, но Вы бы отбросили аспект «модель» для более крупных проектов, особенно если доступ к данным является общим, какой подход вы бы использовали для получения ваших данных?

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

Добавлен дополнительный вопрос в пункт назначения DAL. / 15:42 GMT + 10

Answer 1

Чтобы ответить на ваши вопросы:

• Должен ли я выполнять LINQ to SQL непосредственно в моем сервисном / бизнес-уровне или в DAL в методе репозитория? LINQ to SQL имеет смысл, только если ваша база данных отображается 1-к-1 с вашими бизнес-объектами. В большинстве корпоративных ситуаций это не так, и Entities более уместно.

  Как уже было сказано, LINQ в целом весьма уместно использовать непосредственно на вашем бизнес-уровне, поскольку поставщик LINQ (будь то LINQ to SQL или что-то еще) - это ваш DAL. Преимущество LINQ заключается в том, что он позволяет вам быть гораздо более гибким и выразительным на бизнес-уровне, чем DAL.GetBusinessEntityById(id), но код, близкий к железу, который обеспечивает работу и LINQ, и традиционного кода DAL, инкапсулирован от вас. , имеющий такой же положительный эффект.

• Считаете ли вы, что мы действительно можем использовать POCO (простые старые объекты CLR) при использовании LINQ to SQL? Без более конкретной информации о ваших проблемах с POCO, связанных с LINQ to SQL, сказать сложно.

• вы бы отбросили фасет 'модель' для крупных проектов Шаблон MVC в целом гораздо шире, чем может показаться поверхностный взгляд на ASP.NET MVC. По определению, все, что вы решите использовать для подключения к своим данным, в вашем приложении становится вашей моделью. Если для подключения к облаку данных предприятия используется WCF или MQ, пусть будет так.

Answer 2

Независимо от того, используете ли вы LINQ-to-SQL, часто бывает сложно использовать отдельный объект DTO для таких вещей, как WCF. Я привел несколько соображений на эту тему: Pragmatic LINQ - но для меня самое большое: не выставляйте IQueryable<T> / Expression<...> в интерфейсе репозитория Если вы это сделаете, ваш репозиторий больше не является черным ящиком и не может быть протестирован изолированно, так как он находится на прихоти вызывающего. Кроме того, вы не можете профилировать / оптимизировать DAL в отдельности.

Большая проблема заключается в том, что IQueryable<T> протекает ( LOLA ). Например, Entity Framework не нравится Single() или Take() без явного OrderBy() - но L2S вполне подойдет. L2S должен быть деталью реализации DAL - он не должен определять хранилище.

По аналогичным причинам я отмечаю свойства ассоциации L2S как internal - я могу использовать их в DAL для создания интересных запросов, но ...

Answer 3

Когда я посмотрел на витрину Роба Коннери, казалось, что он использует POCO и Linq to SQL; Однако он делает это путем перевода сущностей, созданных в Linq, в SQL в POCO (и обратно), что мне кажется немного глупым - по сути, у нас есть DAL для DAL.

Однако это единственный способ использовать POCO с Linq to SQL.

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