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 + встроенная БД. Тогда и поставщиков БД можно будет менять как перчатки. Ну или почти...

Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Если ты студент и у тебя есть студенческий билет, то ты можешь получить ряд продуктов бесплатно:
Visual Studio 2008
Visual Studio 2005
XNA Game Studio 3
SQL Server 2008 Developer
Windows Server 2003
Windows Server 2008 Standard
Expression Studio 2


Подробности тут:
Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Необычный подход к написанию юнит тестов

Обнаружил довольно необычный подход к написанию юнит тестов у автора вот этого поста:
Test Driven Design и Test First Development -- в чем разница?

Меня привлекло то, что тест класс представляет из себя наследник тестируемого класса.

Приведу пример классического и альтернативного подхода (пример из документации NUnit).

Тестируемый класс:

namespace bank
{
 public class Account
 {
   private float balance;
   public void Deposit(float amount)
   {
     balance+=amount;
   }

   public void Withdraw(float amount)
   {
     balance-=amount;
   }

   public void TransferFunds(Account destination, float amount)
   {
   }

   public float Balance
   {
     get{ return balance;}
   }
 }
}

Тест, написаный при помощи "классического" подхода:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest
 {
   [Test]
   public void TransferFunds()
   {
     Account source = new Account();
     source.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     source.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, source.Balance);
 
   }
 }
}

Тест, написанный с помощью альтернативного подхода с наследованием:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest : Account
 {
   [Test]
   public void TestTransferFunds()
   {
     this.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     this.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, this.Balance);
   }
 }
}

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


Лично у меня возникает вопрос. А стоит ли вообще так писать тесты?

У меня сходу возникли следующие мысли насчет альтернативного подхода:
+ Наследование позволяет протестировать protected методы
+ Я могу написать helper-методы в тест классе, который будет активно работать с protected методами и свойствами
- Наследование дает бОльшую связность между тестовым и тестируемым классом
- Наследование скорее всего завяжет мне руки в SetUp/TearDown методах
- Если класс sealed, то о подходе с наследованием можно забыть
- Когда я пишу классический тест-метод, то я получаю лаконичную документацию к своему коду в виде маленьких примеров
- Когда я пишу классический тест-метод, то я использую класс точно так же как это делает production-код
- У класса Account будет аж два клиента - production code and unit tests, что как правило будет положительно отражаться на его интерфейсе


Очень интересны ваши мнения на этот счет.

Тест. Какой вы ученый?

Очередное баловство на тему тестов.

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

Как правило это играет мне на руку, хотя иногда все-же делает меня занудой. :)

О, да вы - физик.

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

Пройти тест

IronPython. Ссылки.

Начинаем работать с IronPython.
http://blogs.gotdotnet.ru/personal/AlexanderByndyu/PermaLink.aspx?guid=71d5dcff-7833-4242-ac06-5388ad993acf

Entry point для того чтобы начать работать с IronPython в Visual Studio 2008.


Блог автора языка IronPython:
http://blogs.msdn.com/haibo_luo/default.aspx


IronPython: Grab the .NET Type
http://blogs.msdn.com/haibo_luo/archive/2007/09/25/5130087.aspx

Можно сказать entry point по IronPython/.NET interop. Очень мало, но наглядно :)


IronPython: Keyword Argument to Set .NET Property/Field
http://blogs.msdn.com/haibo_luo/archive/2007/10/02/5246577.aspx

Если кто-нибудь любит свеженькие конструкции C# вроде Object Initializer, то стоит просмотреть этот пост.


IronPython: Passing Arguments for a Call
http://blogs.msdn.com/haibo_luo/archive/2007/10/01/5230964.aspx

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


IronPython: Provide (or not) Argument for by-ref Parameter
http://blogs.msdn.com/haibo_luo/archive/2007/10/04/5284947.aspx

Вызов методов с ref-параметрами.


IronPython Cookbook
http://www.ironpython.info/index.php/Main_Page

Собрание материалов по IronPython.


SimplePrograms
http://wiki.python.org/moin/SimplePrograms

Своеобразные подсказки для тех, кто не хочет держать все время языковые конструкции в голове ;)


DLR Hosting and related stuff...
http://blogs.msdn.com/seshadripv/default.aspx

Релизная версия IronPython 2.0 работает поверх Dynamic Language Runtime. Если вам (не дай бог :) ) придется интегрировать хостинг Python-скриптов с вашим .NET-приложением, то тут можно почерпнуть максимум возможной информации.

Тест. Какая культура вам ближе?

Решил расслабить мозги после тяжелого трудового понедельника очередным тестом :)

Поздравляем!!! Вам ближе американская культура

Вас зовет земля свободы! Вам импонируют американское видение жизни и ценности "нового света".

Пройти тест

KDE 4.2. Релиз для всех.

Выпущен релиз KDE 4.2, который, как утверждают разработчики, уже готов для конечного пользователя.

До этого было два релиза, которые опционально включались в дистрибутивы, однако не были готовы к повседневному использованию простыми смертными.


Обзор. Можно ограничиться просмотром картинок :)
http://adymo.blogspot.com/2009/01/kde4-review-from-inside-out-part-1.html
http://adymo.blogspot.com/2009/01/kde-42-review-from-inside-out-part-2.html

Я с большим интересом наблюдаю за развитием ветки 4.x. Было даже несколько попыток установить его на свой дистрибутив Ubunut. Однако каждый раз я возвращался на стабильный Gnome. Хотя во многих моментах KDE 4.x мне нравится больше чем Gnome.

Отмечу так же что стабильный релиз KDE 3.5 мне вообще не нравился.