Pull to refresh

Comments 48

Хороший обзор. Сам я очень давно не использовал sqlite, еще с момента, когда там были разные прослойки импортирующие методы их не Net сборки. Очень хорошо, что ее закукожили таки в DbProviderFactories.
Хорошая статья. А каковы преимущества использования под .net SQLite, а не SqlCe?
Использование SQLite или SqlCe — вопрос личных предпочтений. Мне в SQLite нравится, что для работы достаточно одного или иногда двух файлов библиотек, чтобы все функционировало. Получается очень компактно.
в SqlCE нету вроде поддержки хранимых процедур, а в SQLLite есть?
Не исследовал эту тему. Но насколько мне известно — SQLite не поддерживает хранимых процедур (в документации по этой теме ничего нет).
тогда действительно выбор основывается на личных предпочтениях…
Помню писал как-то на C++ и SQLite
Можно было определять свои функции на си и использовать потом в SQL запросах
Нее, Sqlite *намного* дальше от «взрослой» RDBMS по сравнению с SqlCE. Другое дело что далеко не всем нужны эти фичи, а sqlite если что можно доточить, исходников там не так уж много.
Нет, в SQLite их тоже нет. Зато есть триггеры ^_^
Вот, кстати, наличие триггеров при отсутствии хранимок как-то удивляет. Если есть триггеры, че бы уже и хранимки не сделать. Ведь по логике они очень близки.
Года три назад писал небольшое десктопное приложение. Тоже нужна была embed база данных. Тогда мой выбор пал на Firebird, там тоже есть embed версия. Сейчас же часто использую SQLite. Кстати, и у MySQL есть embed версия, но ее я не смотрел.
Я тоже пару лет назад несколько приложений небольших делал с embed Firebird, вполне неплохо работало. А вот почему сейчас все же SQLite? Чем-то удобнее оказалось? Спасибо.
Просто я уже давно не под .net пишу, а на Ruby. Во первых там SQLite более популярная, и с лучшей поддержкой. У Firebird возможности конечно по-богаче, но для маленьких приложений они обычно не нужны, а остальные различия стираются слоем ORM.
Понятно. То есть создание на Ruby приложений с БД нисколько не сложней, чем в .NET?
Лично мне кажется, что даже легче. Есть три основные библиотеки для ORM: Sequel, DataMaper и ActiveRecord из Rails. Все они предоставляют объектный маппинг к базе, т.е. непосредственно про SQL можно забыть. Простой пример на Sequel:
#подключились к базе
DB = Sequel.connect('sqlite://test.db') #подключаться можно к любой СУБД, для которой есть адаптер
#создали таблицу
  DB.create_table :limits do
    primary_key :id
    String :ip
    int :clicks, :default => 0
    
    index :ip
  end

#объявили класс с маппингом
#для каждого поля в таблице будет сгенерирован геттер и сеттер
#также в него можно добавить любые свои методы для работы с моделью
#можно создавать отношения типа has-one has-many и many-to-many
#и валидаторы для полей
class Limit < Sequel::Model
end

l = Limit.new
l.ip = "127.0.0.1"
l.save #добавили в базу новую запись
l = Limit.find(:ip => "127.0.0.1") #получили запись из базы


Эти библиотеки можно сравнить c NHibernate, но в силу динамичности языка, и использования соглашений вместо конфигурации, использовать их проще и удобнее.
Потрясающе :)
Я все хотел добраться до Ruby поосваивать, но все руки не доходили. Спасибо за пример!
Всегда пожалуйста:)
Только один совет, лучше начать изучать Ruby с самого Ruby, а не Rails, как обычно делают.
Рельсы меня как раз и не интересуют, а вот приложения было бы интересно…
Простите, не увидел сразу, что поддерживается :)
Данный провайдер так же позволяет задействовать все дополнительные возможности последних версий .NET, такие как LINQ, Entity Framework.
Есть очень хороший пример работы с этой базой в asp.net mvc называется SharpArchitekture. В основном там она используется для написания тестов.
Пример-то хороший, только сама SharpArcitecture — совершенно гадская вещь. Чего стоит их отказ от Spring.net и куча багов и compatibility issue. К сожалению, проект рожден мертвым.
Ну отказ от spring.net вполне правильная вещь. Мне не нравиться xml а fluent spring ну уж очень сырой. И кстати ничего не мешает вернуть его назад. Там практически везде используется CommonServiceLocator так что этот продукт IoC агностичен. Я тоже не особо рад что они выбрали Castl-овский, но мне поменять контейнер на StructureMap заняло час. Куча багов? Хм написал уже проект на нем и что то не нашел. Что Вы имеете в виду под Compatibility issue? Проект очень хороший(для меня по крайней мере) и быстро развивается. В общем каждому свое.
Не совсем с Вами согласен.

Во-первых, Spring.net — это не только IoC-контейнер. Использовать его исключительно в этих целях нет смысла, проще взять NInject. Windsor не сильно отличается от Spring.net по части конфигурации — и там, и там это можно сделать через API, единственное, что у Windsor есть еще Binsor — DSL поверх Boo.

Быстро развивается и нет багов — видимо, я давно его смотрел (еще когда он был на СodePlex, и одного взгляда на исходники хватило, чтобы больше в его сторону и не глядеть)

Насчет container-agnostic — это Вы правильно говорите, поддерживаю.

Насчет compatibility issue — имею в виду, что попытка прикрутить к нему что-нибудь превратится в головную боль. Хотя может, я просто что-то недопонял в нем. Как в нем рулить транзакциями, например?

Я в целом считаю, что он не заслуживает своего громкого названия. Вы сказали, что переход на StructureMap занял час — у меня тоже сложилось ощущение, что весь каркас можно было набросать максимум за несколько дней. Ну и не понравилась работа с t4 — уж очень хрупко там.
Ну спринг это скорее вопрос личного предпочтения.
Как расширить? Да так же как и сам asp.net mvc. Шарп арх это не более чем набор библиотек просто собранных в единый проджект темплейт. Поэтому добавление функциональности достаточно просто. Транзакции. Во первых можно использовать стандартные нхибернейтовские или можно использовать фильтр акшена который весь экшн оборачивает в транзакцию. Насчет т4 согласен это не очень хорошо сделали.
Вот это мне, собсно, и не нравится. Просто набор библиотек, которые еще и связаны кое-как. Мне кажется, свой аналогичный писать будет быстрее, чем доделать или переделать этот.

Насчет транзакций — имхо очень нехорошо использовать родные транзакции NHibernate, потому что завязывать остальной код на них, в том числе и тот, который я собираюсь прикрутить извне — это неправильно. Этим мне и понравится Spring.net, что там есть абстракции для этих дел и многих других.

Спасибо за комментарии.
Спасибо за статью! Как раз сегодня полночи пыталась ЭсКюЛайт в приложение на ДотНет внедрить :)
Чувствую, сегодня ночью внедрю-таки.
Собственно, не очень четко раскрыто, как предлагается использовать SQLite.
Собственный мануалы SQLite рекомендуют использовать ее вместо кастомных форматов файлов — в режиме открыл файл BEGIN TRANSACTION, по сохранению сделал COMMIT.
Т.е. исключительно локально
>Собственно, не очень четко раскрыто, как предлагается использовать SQLite.
Я для себя писал телефонный справочник с использованием SQLite например. Известные примеры использования SQLite есть на википедии, наверное, они лучше всего очерчивают область применения данной СУБД.

>Собственный мануалы SQLite рекомендуют использовать ее вместо кастомных форматов файлов…
Тоже хороший вариант использования. Но я думаю, что SQLite проектировали не только для использования в качестве локального источника данных, личная практика показывает — что SQLite можно без проблем использовать для небольших веб-приложений.
В SQLite все бы хорошо, но неудобно работать со связями. Надо создавать триггеры.
Думаю Вы используете автоматический инструмент. Какой, если не секрет?
Пока мне хватает возможностей Server Explorer из Visual Studio. По крайней мере таблицы, индексы, ключи, констреинты и триггера настраиваются без проблем. Правда я и не использовал SQLite для каких-либо особо сложных баз данных.
Триггеры нельзя с помощью SQLite Designer создавать/редактировать. Только просмотр.
Вообще этот аддон к студии предоставляет довольно скромные возможности.
Если SQLite Designer'а не хватает, то можно воспользоваться этим инструментом SQLite Administrator.

>Триггеры нельзя с помощью SQLite Designer создавать/редактировать.
Подтверждаю. Сам создавал trigger'ы программным способом. Наверное исправят в следующем релизе.
SQLite Administrator программка неплохая, но криво работает с UTF-8/Unicode. И есть немного претензий к интерфейсу, поэтому я сейчас использую аддон к ФФ — SQLite Manager.
Спасибо за упоминание SQLite Manager к FF. Сегодня посмотрю.

А зачем связи во встраиваемой базе данных для дотнета? Связи нужно делать в DataSet-е. Дополнительные связи в БД только все усложнят и не дадут ничего полезного.
Наверно надо точку в конце ссылки убрать ;)
Кстати, SQLite можно прикрутить к мапперу IBatis, и можно использовать интерфейс IBatis, практически не оглядываясь на особенности SQLite.
Меня от использования SQLite.NET остановила неразвитость инструментов (год назад) и отсутствие комерческого вендора который мог бы осуществить комерческую поддержку. Потому выбрал MS SQL Compact. Прямо сравнить сложно, но мне и не очень нужно, нужный мне функционал реализован, больших сложностей не нашёл, с выходом 3.5 SP1 появился EF да и сам движок стал более совершенен, потому от «добра добра не ищут»
— добавил ссылки на System.Data.SQLite и System.Data.SQLite.Linq
— добавил в проект Linq to SQL Classes, открыл в дизайнере
— перетаскиваю SQLite таблицу из Server Explorer
— ошибка:

— Microsoft Visual Studio
— The selected object(s) use an unsupported data provider.
— OK Help
— VS 2008. Что делаю не так? Спасибо.
Как её присоединять с Visual Studio C#- то?
Всё перепробовал- не получилось. Опишите по шагам, пожалуйста. А то не находит System.Data.
Устанавливаете Designer add-in к Visaul Studio и добавляете ссылку на Syste.Data.SQLite.dll (через Add Refrence).
Спасибо!) а можно только вэб-приложения делать? Обычные нельзя?

К си++ не прикрутится?
А то я что только не делал- и сам компилировал dll-библиотеку и разные версии скачивал- компилятор пишет, что не может прочитать dll, либо пару десятков «unresolved external symbol ...» выдаёт.
Для C++ лучше использовать sqlite3.dll. System.Data.SQLite.dll предназначена для управляемого кода.
Only those users with full accounts are able to leave comments. Log in, please.