DAL и BLL разделены одной часто тонкой, но ключевой разницей; бизнес логика. Звучит мрачно просто, но позвольте мне объяснить подробнее, потому что различия могут быть ОЧЕНЬ хорошими и в то же время оказывать огромное влияние на архитектуру.
Используя Linq2SQL, среда генерирует очень простые объекты, каждый из которых представляет одну запись в одной таблице. Эти объекты являются DTO; это легковесные классы POCO (Plain Ol 'CLR Object), которые имеют только поля. Среда Linq2SQL знает, как создавать и обрабатывать эти объекты из данных БД, и аналогичным образом она может переваривать данные, содержащиеся в одном объекте, в SQLDML, который создает или обновляет запись БД. Тем не менее, на этом уровне известно мало или ни одно из правил, регулирующих отношения между полями различных объектов.
Ваша фактическая модель домена должна быть умнее этой; по крайней мере, достаточно умен, чтобы знать, что свойство объекта Order с именем SubTotal должно быть равно сумме всех ExtendedCosts всех OrderLines, и, аналогично, ExtendedCost должен быть продуктом UnitPrice и количества. Во многих современных программах ваш домен является частью вашего BLL, по крайней мере, до такой степени. Объекты, созданные Linq2SQL, вероятно, не должны знать все это, особенно если вы не сохраняете SubTotal или ExtendedCost. Если вы полагаетесь на DTO Linq2SQL, вы в основном привязали себя к тому, что называется моделью анемичного домена, которая является известным анти-паттерном. Если объект домена, по крайней мере, не может поддерживать себя внутренне согласованным, то любой объект, который работает с объектом домена, должен быть доверенным, чтобы сохранить его таким образом, требуя, чтобы все эти объекты знали правила, которые им не должны.
Пользовательский интерфейс должен знать о домене, или, если вы предпочитаете, он должен знать какой-то абстрактный способ получения данных из домена для целей чтения-записи (обычно инкапсулируется в объекты, называемые контроллерами, которые работают с уровнем домена и / или Linq2SQL). Пользовательский интерфейс НЕ должен знать о БД в любой программе среднего размера или больше; либо доменные объекты могут увлажнять себя с помощью ссылки на объекты в DAL, либо они создаются пользовательскими объектами в DAL, которые вы создаете для гидратации, которые затем передаются контроллеру. Подключенная модель ADO и взаимодействие с GridView восхитительны, но не позволяют абстрагироваться. Допустим, вы хотите вставить слой веб-службы между доменом и пользовательским интерфейсом, чтобы пользовательский интерфейс мог быть размещен в мобильном приложении, которое работало с данными в вашем хранилище. Вам придется перестроить свой пользовательский интерфейс, потому что вы больше не можете напрямую получать объекты из Linq2SQL; Вы получаете их из веб-сервисов. Если у вас есть уровень контроллера, который взаимодействует с Linq2SQL, вы можете заменить этот уровень контроллерами, которые взаимодействуют с веб-сервисами. Это звучит как небольшая разница; Вы всегда должны что-то менять. Но теперь вы используете ТОЧНО один и тот же пользовательский интерфейс в мобильных и настольных приложениях, поэтому изменения на ЭТОМ уровне не нужно вносить дважды только потому, что два слоя получают данные разными способами.