Новый проект .NET 3.5:Какую технологию DAL использовать?
-
07-07-2019 - |
Вопрос
Я готовлю новый проект 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.