Каким должен быть правильный BL и DAL?

Не так давно нашел на ряд постов, которые сформировали у меня определенное видение решения классической задачки по передачи данных через ряд уровней - Data access layer -> Business layer -> Presentation layer.

Первым был пост Repository is the new Singleton от Oren Eini aka Ayende Rahien.

В этом посте Ayende говорит что ему не очень нравится непосредственно сам паттерн Repository, более того от отмечает что в большистве случаев этот паттерн еще и не совсем правильно используют.

Дествительно, с появлением LINQ и NHibernate/LinqToSql/ADO.NET Entity Framework подход к получению данных довольно сильно изменился.

И я придерживаюсь того мнения что нужно постепенно уходить от практики написания огромного количества методов вида GetCustomer(id), GetCustomerWithAddresses(id) и начинать использовать механизм запросов даже на верхних уровнях.

Если этого не делать, то мы очень быстро прийдем к достаточно некрасивому Data access layer'у - Kobe – Data Access done wrong.

В своем следующем посте - "The DAL should go all the way to UI" Ayende развивает идею и очень наглядно показывает какую цену приходится платить за неудачную реализацию Data access layer'а.

Действительно, если делать sorting и paging по-честному, через Business Layer, то приходится вручную писать кучу методов, которые похожи друг на друга как близнецы браться, что как раз нарушает принцип DRY (Don't Repeat Yourself).

Подход Ayende мне показался очень уместным, однако меня смутило отсутствие ограничений по извлечению даных на UI-уровне. Возможно, я параноик, но я бы хотел все вызовы по извлечению данных прокидывать через Business Layer. Как минимум это даст возможность прикрутить Caching/Logging/Security на query-методы.

В ответ на пост Ayende, другой блоггер Justin Etheredge сделал пост в котором привел достаточно удачную на мой взгляд реализацию paging'а и сортировки.

В результате, однозначно для себя я решил несколько моментов:
- Классы IRepository должны быть максимально небольшими и простыми
- При получении данных необходимо иметь возможность строить цепочку из filtering, paging, sorting, поскольку это дает намного больше гибкости
- Presentation Layer не должен работать с чрезмерно богатым интерфейсом, этот уровень должен использовать только то, что предоставляет ему Business Layer
- Все большие либо нетривиальные запросы стоит инкапсулировать в отдельные Query-объекты

Интересно, насколько удобно будет использовать это решение когда у нас пользовательский интерфейс написан на Silverlight? Ведь в таких случаях мы Business Layer не видим напрямую в своем Silverlight-приложении, а работаем с удаленными WCF-сервисами.

SQLite для .NET разработчика. Ссылки.

Краткое описание на Wikipedia:
http://ru.wikipedia.org/wiki/SQLite

Обычная энциклопедическая статья, которая в общих чертах описывает функциональность этой встроенной СУБД. Очень радует лицензия продукта, которая Public Domain.


Официальный сайт SQLite
http://www.sqlite.org/

.NET программисту особенно тут делать нечего. Однако стоит прочитать две статьи в разделе Documentation - "Appropriate Uses For SQLite" и "Distinctive Features" чтобы иметь четкое понимание того, как именно позиционируется данный продукт.


SQLite Management Tools
http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

Утилиты, которые позволяют управлять и выполнять запросы к базе SQLite

SQLite Converter Tools
http://www.sqlite.org/cvstrac/wiki?p=ConverterTools

Утилиты для конвертирования форматов других баз данных в формат SQLite и, наоборот.


SQLite Wrappers
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

Библиотеки, которые позволяют обращаться к базе SQLite из различных языков программирования.


System.Data.SQLite
http://sqlite.phxsoftware.com/

Наиболее развитый на мой взглять ADO.NET Data Provider для SQLite.

На официальном сайте можно отметить следующие интересные возможности этого проекта:
- Полная поддержка стека ADO.NET 2.0
- Поддержка .NET, .NET Compact Framework, Mono
- Поддержка ADO.NET Entity Framework, который доступен в .NET 3.5
- Design-Time поддержка в Visual Studio 2008
- Есть возможность шифрования базы данных

Для того чтобы распространять .NET проект, в котором используется база данных SQLite достаточно включить в него сборку System.Data.SQLite.dll, которая сама уже содержит оригинальную библиотеку.
Кроме того, можно использовать альтернативный вариант распространения - включать в дистрибутив приложения сборку System.Data.SQLite.dll из каталога ManagedOnly + оригинальную sqlite3.dll.


[UPDATE 2009-11-26]

Пост вызвыл активную реакцию, чему я безмерно рад. Большое спасибо за фидбек, я получил целый ряд полезных "зацепок", которые в последствии могут пригодится.

Насчет ссылочной целостности в SQLite. Действительно, неделю назад обнаружил в документации что по-умолчанию в SQLite не включены FK Constraints. Да, не фонтан. Пусть даже это и встроенная СУБД, но я бы не отказался от такого полезного механизма контроля.

По ссылке ниже описывается как можно проверить включены ли они или нет и что нужно сделать чтобы их таки включить:
http://www.sqlite.org/foreignkeys.html

Из документации видно, что в будущих релизах FK Constraints могут быть включены.

Плюс еще довольно полезная информация по поводу того, чего SQLite не умеет из SQL92 стандарта:
http://www.sqlite.org/omitted.html

Пока для себя расставил такие приоритеты:
- если размер дистрибутива важен, и можно принебречь остутствием ряда продвинутых фич, то я предпочту SQLite;
- требовать уж очень высокой скорости работы от встроенной СУБД думаю что не стоит;
- Embedded Firebird выгодно отличается от SQLite возможностью с нее "соскочить" на полновесную Firebird. Предполагаю что это будет максимально безполезненно;
- Еще подумываю об необходимости использовании ORM + встроенная БД. Тогда и поставщиков БД можно будет менять как перчатки. Ну или почти...