Во-первых, я прошу прощения, если это не подходящее место для того, чтобы задать этот вопрос, но я не был уверен, где еще можно получить информацию.
Я создал более раннюю версию объекта .NETпостоянная библиотека.Его функции:
- A очень простой интерфейс для сохранения POCO.
- Главное: поддержка практически всех мыслимых носителей данных.Это может быть все: от простых текстовых файлов в локальной файловой системе до встроенных систем, таких как SQLite, любого стандартного сервера SQL (MySQL, postgres, Oracle, SQL Server и т. Д.) До различных баз данных NoSQL (Mongo, Couch, Redis и т. Д.).Драйверы могут быть написаны практически для чего угодно, так что, например, вы можете довольно легко написать драйвер, где фактическим резервным хранилищем может быть веб-сервис.
Когда у меня впервые появилась эта идея, я был убежден, что этопросто восхитительно.Я быстро создал первоначальный прототип.Теперь я нахожусь в «трудной части», где я обсуждаю такие вопросы, как пул соединений, безопасность потоков, а также обсуждаю, стоит ли пытаться поддерживать IQueryable для LINQ и т. Д. И я более тщательно рассматриваю, стоит лиразработать эту библиотеку вне моих собственных требований.
Вот базовый пример использования:
var to1 = new TestObject { id = "fignewton", number = 100, FruitType = FruitType.Apple };
ObjectStore db = new SQLiteObjectStore("d:/objstore.sqlite");
db.Write(to1);
var readback = db.Read<TestObject>("fignewton");
var readmultiple = db.ReadObjects<TestObject>(collectionOfKeys);
Интерфейс запросов, который работает прямо сейчас, выглядит следующим образом:
var appleQuery = new Query<TestObject>().Eq("FruitType", FruitType.Apple).Gt("number",50);
var results = db.Find<TestObject>(appleQuery);
Я также работаю над альтернативным интерфейсом запросов, который позволяет просто передавать что-то очень похожее на предложение SQL WHERE.И, очевидно, в мире NET было бы замечательно поддерживать деревья IQueryable / выражений.
Поскольку библиотека поддерживает множество носителей данных с разными возможностями, она использует атрибуты, чтобы помочь системе наилучшим образом использовать каждый драйвер.
[TableName("AttributeTest")]
[CompositeIndex("AutoProperty","CreatedOn")]
public class ComplexTypesObject
{
[Id]
public string id;
[QueryableIndexed]
public FruitType FruitType;
public SimpleTypesObject EmbeddedObject;
public string[] Array;
public int AutoProperty { get; set; }
public DateTime CreatedOn = DateTime.Now;
}
Все атрибуты являются необязательными и в основном связаны с производительностью.В простом случае вам не нужен ни один из них.
В среде SQL система по умолчанию позаботится о создании таблиц и индексов для вас, хотя есть опция DbaSafe, которая предотвращает работу системы.от выполнения DDL.
Также интересно иметь возможность переносить ваши данные, скажем, с механизма SQL на MongoDB в одной строке кода.Или в почтовый файл.И снова.
ОК, Вопрос:
Основной вопрос: «Это полезно?»Стоит ли тратить время на то, чтобы действительно отшлифовать, сделать потокобезопасным или создать пул соединений, написать лучший интерфейс запросов и загрузить куда-нибудь?
- Есть ли уже другая библиотека, которая уже делает что-то подобноеИМЕННО, предоставляя единый интерфейс, который работает с несколькими источниками данных (помимо просто разных разновидностей SQL)?
- Это решает проблему, которую нужно решить, или кто-то другой уже решил ее лучше?
- Если я продолжу, как вы попытаетесь сделать ваш проект видимым?
Очевидно, что это не замена ORM (и она может сосуществовать с ORM и сосуществоватьс вашим традиционным сервером SQL).Я предполагаю, что его основные варианты использования предназначены для простого сохранения, когда ORM является избыточным, или для сценариев типа NoSQL, и где интерфейс типа хранилища документов предпочтителен.