Вопрос

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

Я планирую использовать клиент WPF (MVVM) и службу WCF в трехуровневой системе.

Подводя итог всем существующим технологиям, с которыми я знаком:

Наборы данных

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

ПРОТИВ:Довольно старомодно.Некоторые считают их не реальными бизнес-объектами/моделями, а просто зеркалом ваших таблиц данных SQL.Передача их между службой/клиентом WCF может быть сложнее, чем самостоятельно созданные бизнес-объекты.

Корпоративная библиотека 4.1 — Блок доступа к данным

ПРО:DAL прекрасно вписывается в шаблон Factory.Он автоматически обеспечивает открытие и закрытие соединения.По большей части очень прост в использовании.Он поддерживает как наборы данных, так и обычные SQL-службы для создания собственных бизнес-объектов.В рамках существующей платформы гораздо эффективнее использовать ее в сочетании с остальной частью корпоративной библиотеки для получения эффективного конечного продукта.

ПРОТИВ:??

Linq для SQL

ПРО:Автоматически создает таблицы SQL в бизнес-объекты.Легко использовать CRUD.Теоретически очень хороший способ сделать это.

ПРОТИВ:Поигравшись с ним, когда он вышел, я нашел его ненадежным и иногда нестабильным.Эта технология уже считается мертвой после того, как Microsoft объявила, что Entity Framework 4.0 — как часть .NET 4.0 — будет рекомендованным Microsoft способом.В .NET 4.0 ожидается лишь несколько исправлений ошибок, но планов по расширению функций больше не будет.

Entity Framework 4.0

Ничего о нем не знаю, а только то, что со временем оно заменит все остальное, что и на .NET 4.0.У меня также возникает соблазн использовать его, однако, поскольку он все еще находится в стадии БЕТА, я пока не смогу пойти по этому пути.

У меня очень возникает соблазн использовать Enterprise Library 4.1 — Data Access Block и создать свои собственные бизнес-объекты.Большой минус в том, что для создания DAL потребуется больше времени.Если только кто-нибудь не убедит меня использовать вместо этого наборы данных через блок доступа к данным.

Каковы ваши комментарии и идеи?Большое спасибо, Кав

Это было полезно?

Решение

Вы упоминаете Entity Framework как часть "contra" для варианта Linq to SQL, но вы должны рассмотреть его вместо Linq to SQL - он предоставляет практически те же функции и больше. Для проектов с небольшими базами данных, это определенно много денег. В EF может быть сложно управлять контекстом для больших баз данных, а изменения схемы могут привести к поломке, но эти проблемы возникают при любом подходе к доступу к данным.

Самым большим минусом для EntLib, на мой взгляд, является то, что вы все еще катите свои собственные объекты данных. Корпоративная библиотека забирает много сантехнического кода у простого «старой школы» Хорошая реализация ADO.NET, но она не генерирует для вас объекты данных, которые можно использовать «из коробки» для запросов LINQ.

Другие советы

Мы обычно использовали DataSets с блоком прикладных данных EntLib 4.1.

Теперь мы используем Entity Framework. Мы добились огромного улучшения производительности с Entity Framework по сравнению с EntLib 4.1. (Выполните прогон слоя данных для 80 таблиц за 10 часов вместо 80)

Entity Framework 4 все еще находится в бета-версии, но если пройдет некоторое время, прежде чем ваш проект будет запущен, я перейду к EF 4. При этом вы получаете производительность ORM и гибкость использования POCO (Plain Old Clr Объекты)

А.Проверьте также NHibernate.

Б.DataSet — самый быстрый и простой, но вы много кодируете.

В остальном — в использовании ORM-инструментов много хорошего, но с 3-х уровневой у них много проблем.

(ленивая загрузка — это проблема, с которой приходится иметь дело, создание большого количества больших деревьев объектов, которые влияют на производительность, кеширование не настолько умно, насколько это возможно)

Итак, это зависит от ваших основных потребностей и от того, сколько времени вы хотите потратить на изучение EL/LINQ или NHibernate, прежде чем начать программировать, потому что с этими инструментами ЕСТЬ кривая обучения.

Лучшая идея - иметь возможность использовать обе технологии одновременно. Как ты можешь это сделать? С шаблоном репозитория это очень просто. Сначала вам нужно создать общий интерфейс IRepository. Что-то нравится это:

public interface IERepository<E>
{
    DbTransaction BeginTransaction();
    void EndTransaction();
    void Add(E entity);
    void Delete(E entity);
    int Save();

    ObjectQuery<E> DoQuery(string entitySetName);
    IList<E> SelectAll(string entitySetName);
    E SelectByKey(int Key);

    bool TrySameValueExist(string fieldName, object fieldValue, string key);
    bool TryEntity(ISpecification<E> selectSpec);

    int GetCount();
    int GetCount(ISpecification<E> selectSpec);
    int AddAndSave(E entity);

}

Я предпочитаю Entity Framework. Я создал 3 проекта на его основе. Работает очень быстро, особенно запросы с подкачкой. Итак, после вам нужно создать базовый универсальный класс Repository с виртуальными методами, которые реализуют интерфейс IRepository. И это все.  Теперь у вас есть очень быстрый способ создания DAl для написания простого кода, подобного следующему:

public class MonthRepository:Repository<Month>
{

}

У вас есть возможность переопределить все методы базового класса и создать доступ к БД, используя хранимую процедуру там, где вам нужно. И вы можете обойтись без изменения кода в других местах. Вы все равно вернете сущности того же типа, но получите их другим способом.

Узнайте больше на http://www.codeproject.com/KB/database/ ImplRepositoryPatternEF.aspx

NHibernate обладает наилучшим сочетанием набора функций, зрелости и поддержки.

NHibernate, Entity Framework, активные записи или linq2sql

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top