Большая часть сказанного - твердый совет.Я согласен с тем, что если вы хотите потратить время на создание приложения N-уровня, вам следует подумать о поиске решения ORM.Если вы используете технологии .NET, EF4 - очень хороший подход к созданию вашего DAL.
Существует определенная путаница в понимании того, что должен возвращать ваш DAL / BLL.DataSets сейчас немного устарели в .NET 3 и 4, хотя и нередки.Вы должны прочитать шаблон проектирования репозитория при создании вашего DAL.В зависимости от реализации ваш репозиторий обычно возвращает общий List<T> or IQueryable<T>.Я предпочитаю IQueryable, однако утверждается, что он стирает границы между вашим BLL и DAL.
Некоторые реализации также требуют, чтобы у каждого агрегата был свой собственный репозиторий.(т. е. CustomerRepository, EmployeeRepository). Я считаю, что проще всего создать универсальный репозиторий, в котором тип имеет ограничение.
Так, например:
Repository<TEntity> : IRepository<TEntity> where TEntity : ITrackable
Чтобы увидеть отличный подход к разработке вашего DAL, взгляните на nCommon .Тони Снид (Tony Sneed) имеет отличную серию блогов по использованию Entity Framework с POCO: http://blog.tonysneed.com/2010/02/19/trackable-dtos-taking-n-tier-a-step-further-with-ef4/
Время, потраченное на разработку уровня DAL и домена, является критическим.
Мой совет субъективен и не должен бытьпринимается как правильный или неправильный.Я не знаю требований вашего приложения.Окупаемость инвестиций может быть выше для вас, если вы сможете быстрее разработать некоторый код с помощью простых наборов данных и sqldatareaders.Если вы хотите создать поддерживаемый дизайн, потратьте дополнительное время на чтение шаблонов архитектуры EF4 и N-Layer, как предлагали другие.
[EDIT]
В ответ на ваш комментарий ниже я подумал, что могу поделиться некоторыми ценными ресурсами, которые я нашел в обучении архитектуре.
Прежде всего будьте готовы посвятить бесчисленные часы чтению и перечитыванию.Используя свои текущие знания и с постоянной практикой, применяя то, что вы изучаете.Самая важная вещь, которую нужно осознать: ваш дизайн никогда не будет идеальным, потому что такой вещи нет, и только потому, что вы применяете шаблон, не обязательно делает его лучшим.
Наличие ваших личных проектов неоценимо для продвижения вперед.в ООП.В книге «Выпадающие» Малкольма Гладуэлла он теоретизирует, что в среднем требуется 10000 часов практики, прежде чем вы сможете что-то освоить.Так что продолжайте кодировать и учиться.:)
Одна из лучших книг, которую вы можете взять - Head First - Design Patterns .Это высоко ценится как феноменальная вводная книга для OOD и меняет ваш взгляд на код.Я помню, как прочитал несколько глав и сразу понял: «Ух ты! Я все время писал такой код, но никогда не знал, что для него есть названия!»Это помогло мне понять, насколько знакомы проблемы дизайна;что для них есть общие решения, и насколько важно иметь возможность общаться с другими разработчиками.Эта книга серьезно ударит вас по заднице (в хорошем смысле).
Обратите внимание, однако, что книги по архитектуре и дизайну дадут вам сценарий, в котором применяется как дизайн, так и реализацию шаблона.Мне потребовалось немного времени, чтобы понять, что может быть много способов реализовать шаблон ... особенно в .NET.Вы увидите, что когда вы начнете читать книги Мартина Фаулера, Роберта С. Мартина, Эрика Эванса, Дино Эспозито.
Есть много отличных ресурсов для бесплатного онлайн, таких как Руководство по архитектуре приложений * 1040 от Microsoft*.Одними из лучших способов изучения техники являются просто чтение блогов.
Для Entity Framework трудно превзойти Programming EF4 Джулии Лерман.Что касается разъяснения роли ORM - она облегчает связь с вашей базой данных и позволяет вам «запрашивать» ее, как если бы она была объектно-ориентированной.Так, например, некоторый псевдокод:
С SqlDataReader вы обычно запускаете запрос типа
"SELECT * FROM Users WHERE Users.UserId = 1"
С ORM вы фактически не пишете SQL. ORM отображает ваши таблицы базы данных на реальные объекты класса, что позволяет вам выполнять запросы к строго типизированным объектам. Так что вы бы написали что-то вроде:
User user = EFContext.Users.Where(u => u.UserId == 1).SingleOrDefault();
ORM отвечает за перевод этого в SQL и выполнение запроса. Эта абстракция также позволяет ORM работать с несколькими базами данных (MSSQL, Oracle, MySql) через расширяемость провайдера.
Когда вы начинаете использовать многоуровневую архитектуру, ваш Репозиторий отвечает за связь с ORM или базой данных и возврат ваших результатов в ваш BLL. Например, базовый пример будет выглядеть примерно так:
using (var repository = new Repository<User>())
{
User user = repository.Where(u => u.UserId == 1).SingleOrDefault();
}
Это очень элементарное определение ORM и того, как оно используется. Когда вы начнете изучать шаблоны: как их распознавать, когда их использовать (не всегда, так как они могут усложнить что-то простое) и реорганизовать ваш собственный код, тогда начинайте читать в управляемом доменом дизайне.
Надеюсь, это поможет.
[РЕДАКТИРОВАТЬ 2]
Конечно, позвольте мне прояснить, что на самом деле возвращается каждым слоем. В зависимости от реализации вашего репозитория и ваших проектных решений:
С вашего уровня инфраструктуры , где находится ORM, вы обычно возвращаете либо универсальный List<T>, либо IQueryable<T>, где T представляет ваш объект. Будь то объект Entity или POCO, решать только вам. POCO - это просто класс, который представляет ваши данные, но это не просто мешки добытчиков и сеттеров. Он должен содержать проверку как минимум. Читайте о анемичных моделях доменов и о том, как их избежать.
Из уровня вашего домена , который содержит вашу бизнес-логику, в зависимости от того, насколько слабой связи вы пытаетесь достичь, вы либо вернете List<T>, BindingList<T>, либо будете использовать метод сопоставления возврата коллекции DTO на уровни представления и обслуживания.
DTO добавляют еще ряд осложнений, но они необходимы для некоторых сценариев. DTOs являются неизменными объектами. Они должны быть построены так:
[DataContract]
public sealed class UserSummary : IDto
{
[DataMember]
public String FirstName { get; private set; }
[DataMember]
public String LastName { get; private set; }
[DataMember]
public UserProfile Profile { get; private set; }
public UserSummary(String firstName, String lastName, UserProfile profile)
{
FirstName = firstName;
LastName = lastName;
Profile = profile;
}
}
Они являются только мешками добытчиков и сеттеров. Ваши POCO должны легко подключаться к ним, и есть отличное программное обеспечение для упрощения этого процесса: AutoMapper . Они не обязательно должны представлять точные таблицы в вашей базе данных или объектах POCO, но могут состоять из нескольких частей, как показано выше.
Есть один улов. Иногда DTO недостаточно для возврата к вашим услугам или веб-интерфейсу. Обычно вам также нужно возвращать результаты проверки, информацию об обработке ошибок, возможно, логическое значение для выражения результата транзакции.
Нет точного имени для этого объекта, но я продолжал называть его Объектом Передачи Ответов, который составляет List<IDto>, ValidationResults из корпоративной библиотеки Microsoft и все остальное, что мне нужно знать.
Это много информации для потребления. Изучая разработку NLayer, разбивайте ее, как каждый слой. Занимайтесь изучением одной вещи за раз и запишите все вопросы, которые возникают у вас в голове. Обязательно найдите эти ответы.