Уровни .NET и базы данных

Когда я в последний раз работал над программированием, мы пытались отойти от DataReaders и традиционного ADO.NET API к объектно-реляционному сопоставлению (ORM).

Для этого мы сгенерировали DataContext нашей БД через sqlmetal. Затем был тонкий слой данных, который сделал DataContext private, и любой код, нуждающийся в доступе к базе данных, должен был бы использовать метод public в этом тонком слое данных. Эти методы были в основном хранимыми процедурами; они будут выполнять запросы в базе данных через LINQ to SQL.

Это общий подход сегодня? Я имею в виду, это все, кто использует фреймворк .NET 3.5, который действительно запускает sqlmetal в процессе сборки или что? В то время это выглядело как хак.

В принципе, я хотел бы знать, будет ли LINQ to SQL и sqlmetal ожидать, если я начну писать DAL сегодня в магазине .NET 3.5, в котором не используется сторонний open-source ОРМ.

Ответ 1

Ваш подход хорош. В настоящее время я использую услуги Astroria (ADO.NET Data Services). Было замечательное введение в MSDN Magazine об этом.

Мне также нравится новый PLINQO (требуется CodeSmith Tools хотя). По-моему, это очень скользко.

Когда у меня есть такой DAL (сервисный уровень), я просто использую эту услугу из своего клиентского приложения (Silverlight или ASP.NET MVC).

Ответ 2

По-прежнему считается лучшей практикой иметь некоторый уровень доступа к данным. Лучше всего это достигается с помощью ORM - это серьезная дискуссия. Есть одна фракция, которая обычно утверждает, что ORM - это путь. Другая фракция утверждает, что хранимые процедуры и центр базы данных - лучший маршрут.

Кроме того, это может быть не совсем то, что вы имели в виду, но похожее (а также одно в моей кабине)

http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf

Ответ 3

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

Для большинства моих проектов я проектирую его так.

Репозиторий содержит экземпляр DataContext и предоставляет некоторые базовые методы добавления/удаления
ProductRepository: репозиторий предоставляет общие запросы (IQueryable)
StoreService использует экземпляр разных репозиториев, таких как ProductRepository, SalesRepository и обрабатывает всю логику для создания чего-то вроде продукта.

Так что-то вроде...

StoreService.CreateProduct(/* properites */)

Это вернет некоторый класс результатов.

Ответ 4

Лучшим слоем данных является тот, который является простым и простым и выполняет задание без каких-либо свистов. Я использовал упомянутые вами технологии и написал о них здесь: Единственный шаблон для доступа к данным - нет шаблонов для доступа к данным

Ответ 5

Этот сайт использует LINQ to SQL, поэтому сделайте это как угодно.

Официально Microsoft поддерживает Entity Framework над LINQ to SQL с точки зрения новой разработки. Тем не менее, есть вокальная группа людей, которые думают, что EF - неправильный путь. LINQ to SQL по-прежнему будет работать в течение некоторого времени и является очень приличным ORM, если несколько ограничить использование бэкэнда базы данных.

Я бы порекомендовал LINQ как отличную отправную точку для вашего ORM. Если вам нужно лучше, загляните в EF и/или NHibernate.

Ответ 6

"Является ли этот общий подход сегодня? Я имею в виду, что все, кто использует платформу .NET 3.5, действительно запускают sqlmetal в процессе сборки или что?"

Люди, которых я знаю, используя 3.5 Framework (и это почти все) - подавляющее большинство - все еще используют NHibernate. Версия 2.0 - очень хороший OR/M. Я начал использовать его в недавнем проекте и значительно сократил свой код доступа к данным до такой степени, что я действительно не хочу использовать что-либо еще в будущем. И Fluent NHibernate API делает некоторые успехи для людей, которым не нравится XML-сопоставление.