LINQ to SQL архитектура. Что лучше?

Question

Этот вопрос как бы пул. Мы пытаемся определить лучшую архитектуру, используя ORM, такой как LINQ to SQL. Определяемая нами архитектура предназначена для того, чтобы другие приложения могли обращаться к ней либо через прямую ссылку на DLL, либо через веб-сервис. У нас есть приложения .NET и PHP.

Возможны следующие варианты:

Несколько контекстов данных: Разделение базы данных на единицы работы и создание отдельных контекстов для каждого из них.

Плюсы:

• Простота использования
• Классы будут разбиты на разные пространства имен
• Меньший домен для обслуживания

Минусы:

• Объекты должны дублироваться, если связанные, создающие обслуживание ада
• Объекты не могут быть переданы между контекстами, что создает необходимость для другого попадания в базу данных

Единый контекст данных: все таблицы, представления, процедуры находятся в одном огромном контексте.

Плюсы:

• Без дублирования
• Отношениями легко управлять, по сути, LINQ позаботится об этом.
• Лучшая производительность, меньше обращений к БД.

Минусы:

• Все таблицы находятся в одном пространстве имен, завершение кода становится чокнутым
• Не лучший для дизайнера (по крайней мере, на VS2008)
• Не может быть избирательно в том, что сохранять, а что нет. Сохранить все или удалить весь режим.

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

Спасибо всем

Answer 1

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

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

Другой аспект, который я понял во время учений, заключается в том, что использование LinqToSql напрямую неэффективно с точки зрения организации. Если у вас есть проект, в котором команда будет выполнять разработку, а не только одного человека, вы должны «оградить» LinqToSql от них. Должен быть «шериф», который будет работать с доменом, и вы также должны использовать некоторый механизм абстракции для защиты модели от злоупотреблений (я реализовал шаблон репозитория, и он работал хорошо, но вы могли найти другие подходы).

Я также столкнулся с проблемой создания некоторых логических групп внутри домена. В действительности я использовал некоторые методы DDD (Domain Driven Design) для создания так называемых агрегатов. Агрегаты - это логическое расположение объектов внутри домена, где у вас есть корневой объект (который работает как агрегатор) и несколько других спутниковых объектов, связанных между собой. Вы можете сделать это, создав несколько новых объектов в домене LinqToSql. Эти новые объекты будут отключены от базы данных и будут работать как агрегаторы. Этот подход позволит вам создавать «субдомены» внутри вашего домена и поможет вам улучшить дизайн.

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

Я публикую (пока не закончено) шаги, которые я предпринял во время упражнения, в своем блоге: http://developmentnirvana.blogspot.com/

Answer 2

На мой взгляд, контекст данных прячется прямо за интерфейсом репозитория, что позволяет нам менять местами реализацию, если нам нравится (LINQ-to-SQL / EF / NHibernate / LLBLGen / и т. Д.). Таким образом, специфика контекста (ов) данных является в значительной степени подробностью реализации. Пока он проходит юнит-тесты; -p

Огромная редко хорошая идея; Tiny редко используется ... Я склонен разбивать систему на связанные куски (обычно связанные с различными интерфейсами репозитория) и думать об этом на этом уровне. У меня есть некоторые другие мысли здесь: Прагматическое LINQ - хотя я бы с радостью полагался на любую мудрость от Франс и т. Д.

Answer 3

При использовании LINQ to SQL необходимо учитывать еще два момента:

1. Хотя это не устарело, Microsoft заявила, что в центре внимания будущего развития будет Entity Framework, а не LINQ to SQL
2. LINQ to SQL напрямую связывает вас со структурой вашей базы данных. Если вы используете Entity Framework, вы сможете проектировать свои объекты таким образом, который не зависит от реализации вашей базы данных. Например, если вы решите разделить одну сущность на две таблицы, вашим абонентам не нужно будет знать.

Answer 4

Итак, после примерно года разработки в нескольких контекстах, я понял, что нецелесообразно использовать несколько контекстов, проблема возникает, когда у вас есть таблица, которая действительно должна существовать в 2 или более контекстах, обычно от многих до много отношений. Что произойдет, так это то, что посередине может быть вставлена ​​запись только тогда, когда в две другие таблицы вставлены записи, поэтому, если вы используете L2S, как и для других вопросов, эта запись будет создана первой с FK, равными 0 ( Ноль), и это недопустимо (Ссылочная целостность), что приводит к ошибке. Это одно из неудобств, которое я нашел, но я мог бы перечислить еще несколько, если потребуется. Теперь я использую решение для создания «Планировщика», этот парень отвечает за ожидание выполнения определенных условий (оба родителя имеют действительный идентификатор, отличный от 0 (ноль)), затем он вставляет, это делается очень в общем, чтобы разрешить столько специализаций, сколько мне нужно (у меня есть 6 контекстов), и он использует событие PropertyChanged для уведомления об изменениях в планировщике.

Итак, самая важная вещь в этом посте - ИСПОЛЬЗУЙТЕ ЕДИНЫЙ КОНТЕКСТ, что если вам не нравятся головные боли (я вообще не люблю). Затем, после всего сказанного, кто-то может спросить, почему я продолжил работу с несколькими контекстами, ну, допустим, это было решение, которое пришло выше меня, и у меня не было сил, чтобы сопротивляться. (Все, хотя я действительно старался, трудно)