Каков наилучший способ настроить доступ к данным для проекта ASP.NET MVC?

Question

Я начинаю новый проект ASP.NET MVC, чтобы изучить его, и мне интересно, каков оптимальный способ настройки проектов для подключения к серверу SQL для данных. Например, давайте представим, что у нас есть таблица Product и объект продукта, который я хочу использовать для заполнения данных в моем представлении.

Я знаю где-то здесь, у меня должен быть интерфейс, который будет реализован, и т. Д., Но я не могу сегодня обдумать это: - (

РЕДАКТИРОВАТЬ: Прямо сейчас (то есть: текущая, плохо закодированная версия этого приложения) Я просто использую старый старый сервер SQL (даже 2000), используя только хранимые процедуры для доступа к данным, но я не буду препятствовать добавлению в дополнительный уровень гибкости для использования linq to sql или что-то.

РЕДАКТИРОВАТЬ # 2: Я хотел бы добавить одну вещь: я буду писать это для V1 базы данных, и мне нужно будет разрешить нашему администратору базы данных заново обрабатывать базу данных и позже предоставить мне V2. , поэтому было бы хорошо, если бы действительно пришлось изменить несколько небольших вещей, которые не предоставлены через базу данных сейчас, что будет позже. Вместо того, чтобы переписывать совершенно новый DAL.

Answer 1

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

Я пытался охватить некоторые из здесь :

Answer 2

Я бы посмотрел Роба Конери видео о его создании магазина MVC. Серию можно найти здесь: MVC Store Front Series

Эта серия статей посвящена всевозможным предметам, связанным с дизайном, а также технологиям кодирования / тестирования для использования с MVC и другими проектами.

Answer 3

Я сделал несколько приложений MVC и нашел структуру, которая очень хорошо работает для меня. Он основан на серии MVC магазина Роба Конери , упомянутой JPrescottSanders (хотя ссылка, которую он разместил, неверна).

Итак, здесь я обычно пытаюсь ограничить свои контроллеры только логикой представления. Это включает в себя извлечение данных для передачи в представления и сопоставление данных, передаваемых из представления в модель предметной области. Ключ в том, чтобы попытаться не допустить бизнес-логики в этот слой.

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

Итак, в вашем примере products это будет означать, что у вас будет ProductRepository с такими методами, как GetProducts () и SaveProduct (Product product). У вас также будет ProductService (который зависит от ProductRepository) с такими методами, как GetProductsForUser (пользователь-пользователь), GetProductsWithCategory (категория категории) и SaveProduct (продукт-продукт). Такие вещи, как проверка также будет происходить здесь. Наконец, ваш контроллер будет зависеть от уровня обслуживания для получения и хранения продуктов.

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

Answer 4

Я думаю, что архитектура S # arp Билли МакКафферти является довольно хорошим примером использования ASP.NET MVC со слоем доступа к данным (по умолчанию используется NHibernate), внедрения зависимостей (Ninject atm, но есть планирует поддержку CommonServiceLocator) и разработку через тестирование. Фреймворк все еще находится в разработке, но я считаю его достаточно хорошим и стабильным. Начиная с текущего выпуска, до окончательного выпуска должно быть несколько критических изменений, поэтому его кодирование должно быть в порядке.

Answer 5

В решении моего сайта у меня есть проект веб-приложения MVC и «общий» проект, который содержит мои POCO (обычные объекты C #), бизнес-менеджеров и уровни доступа к данным.

Классы DAL привязаны к SQL Server (я их не абстрагировал) и возвращают POCO бизнес-менеджерам, которых я вызываю со своих контроллеров в проекте MVC.

Answer 6

я думаю, что вам нужна форма.

например, структура сущности (сначала код)

Вы можете создать некоторый класс для модели.

используйте эти модели для своей логики и представления и сопоставьте их с дБ (v1).

когда dba дает вам новый db (v2), измените только конфигурацию отображения (v1 и v2 - все rdb, sql server, mysql, oracel ...), если db (v1) - это rdb и db (v2 ) это nosql (монго, redis, couchbase ...), это не работает

может понадобиться найти и заменить

Answer 7

Я только что сделал свой первый проект MVC и использовал шаблон проектирования Service-Repository. Сейчас в сети есть немало информации об этом. Это сделало мой переход от Linq-> Sql к Entity Framework легким. Если вы думаете, что собираетесь многое изменить, добавьте немного дополнительных усилий для использования интерфейсов.

Я рекомендую Entity Framework для вашего DAL / Repository.

Answer 8

Используйте LINQ. Создайте файл LINQ to SQL и перетащите все нужные вам таблицы и представления. Затем, когда вы вызываете свою модель, все ваши вещи уровня CRUD создаются для вас автоматически.

LINQ - лучшее, что я видел за долгое время. Вот несколько простых примеров для получения данных из блога Скотта Гу.

Учебник LINQ

Answer 9

Проверьте сервер Code Camp , чтобы найти хорошее справочное приложение, которое делает именно это, и, как сказал @haacked, абстрагируется от разлуки.

Answer 10

Для нашего приложения я планирую использовать LINQ to Entities, но, поскольку он для меня новый, есть вероятность, что я захочу заменить его в будущем, если он не будет работать так, как мне хотелось бы, и использовать что-то еще, например LINQ. в SQL или NHibernate, поэтому я буду абстрагировать объекты доступа к данным в абстрактную фабрику, чтобы реализация была скрыта от приложения.

Как вы это сделаете, зависит от вас, если вы выберете проверенный и хорошо знакомый шаблон проектирования для реализации, я думаю, что ваш конечный продукт будет хорошо поддержан и надежен.