Новый проект .NET 3.5: какую технологию DAL использовать? - PullRequest
Новая
       31

Новый проект .NET 3.5: какую технологию DAL использовать?

7 голосов
/ 29 ноября 2009

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

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

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

DataSets

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

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

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

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

CONTRA: ??

Linq to SQL

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

CONTRA: Поиграв с ним, когда он вышел, я обнаружил, что он шелушится и иногда нестабилен. Это уже считается мертвой технологией после объявления Microsoft, что Entity Framework 4.0 - как часть .NET 4.0 - будет рекомендованным Microsoft способом. В .NET 4.0 слишком мало исправлений ошибок, но планов расширения возможностей больше нет.

Entity Framework 4.0

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

Мне очень хочется использовать Enterprise Library 4.1 - Блок доступа к данным и создавать свои собственные бизнес-объекты. Большой минус в том, что создание DAL займет больше времени. Если кто-то не сможет убедить меня в использовании DataSets через блок доступа к данным.

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

Ответы [ 5 ]

3 голосов
/ 29 ноября 2009

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

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

2 голосов
/ 29 ноября 2009

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

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

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

1 голос
/ 29 ноября 2009

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

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

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

1 голос
/ 29 ноября 2009

Лучшая идея - иметь возможность использовать обе технологии одновременно. Как ты можешь это сделать? С шаблоном репозитория это очень просто. Сначала вам нужно создать общий интерфейс 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

1 голос
/ 29 ноября 2009

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

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

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

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

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

...