c# - litedb - ¿Es útil mi idea para una biblioteca de persistencia de objetos?

mongodb entity framework c#

Question

Primero, me disculpo si este no es un lugar apropiado para hacer esta pregunta, pero no estaba seguro de dónde más obtener información.

Creé una versión temprana de una biblioteca de persistencia de objetos .NET. Sus características son:

• Una interfaz muy simple para la persistencia de POCOs.
• Lo principal: soporte para casi cualquier medio de almacenamiento concebible. Esto sería todo, desde archivos de texto plano en el sistema de archivos local, a sistemas integrados como SQLite, cualquier servidor SQL estándar (MySQL, postgres, Oracle, SQL Server, lo que sea), a varias bases de datos NoSQL (Mongo, Couch, Redis, lo que sea). Los controladores se pueden escribir para casi cualquier cosa, así que, por ejemplo, podría escribir fácilmente un controlador donde la tienda de respaldo real podría ser un servicio web.

Cuando tuve esta idea por primera vez, estaba convencido de que era totalmente increíble. Rápidamente creé un prototipo inicial. Ahora, estoy en la "parte difícil" en la que estoy debatiendo cuestiones como la agrupación de conexiones, la seguridad de subprocesos y el debate sobre si intentar o no admitir IQueryable para LINQ, etc. Y analizaré más detenidamente si vale la pena hacerlo. desarrollar esta biblioteca más allá de mis propios requisitos para ello.

Aquí hay un ejemplo básico de uso:

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);

La interfaz de consulta que funciona ahora se ve así:

var appleQuery = new Query<TestObject>().Eq("FruitType", FruitType.Apple).Gt("number",50);
var results = db.Find<TestObject>(appleQuery); 

También estoy trabajando en una interfaz de consulta alternativa que le permite transmitir algo muy parecido a una cláusula SQL WHERE. Y, obviamente, en el mundo NET sería genial apoyar los árboles IQueryable / expression.

Debido a que la biblioteca admite muchos medios de almacenamiento con capacidades dispares, usa atributos para ayudar al sistema a hacer el mejor uso de cada controlador.

[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;
}

Todos los atributos son opcionales y básicamente se trata de rendimiento. En un caso simple, no necesitas ninguno.

En un entorno SQL, el sistema se ocupará por defecto de crear tablas e índices para usted, aunque existe una opción DbaSafe que evitará que el sistema ejecute DDL.

También es divertido poder migrar sus datos desde, digamos, un motor SQL a MongoDB en una línea de código. O a un archivo zip. Y de regreso.

OK, la pregunta:

La pregunta de raíz es "¿Esto es útil?" ¿Vale la pena tomarse el tiempo para pulir realmente, hacer que la conexión a subprocesos o la conexión se agrupen, escribir una mejor interfaz de consulta y subir a alguna parte?

• ¿Ya hay otra biblioteca que hace algo como esto, NORMALMENTE, proporcionando una única interfaz que funciona a través de múltiples fuentes de datos (más allá de solo diferentes variedades de SQL)?
• ¿Está resolviendo un problema que necesita ser resuelto, o alguien más ya lo ha resuelto mejor?
• Si continúo, ¿cómo haces para tratar de hacer que tu proyecto sea visible?

Obviamente, esto no reemplaza a los ORM (y puede coexistir con los ORM y coexistir con su servidor SQL tradicional). Supongo que sus casos de uso principales son para la persistencia simple donde un ORM es exagerado, o para escenarios de tipo NoSQL y donde es preferible una interfaz de tipo de almacén de documentos.

Answer 1

Ben, creo que es increíble. Por lo menos, publicarlo en CodePlex y compartirlo con el resto del mundo. Estoy bastante seguro de que hay desarrolladores que pueden usar un marco de persistencia de objetos (o ayudar a pulirlo).

Answer 2

Mi consejo: escríbalo para tus propios requisitos y luego abre el código. Pronto sabrá si hay mercado para eso. Y, como beneficio adicional, encontrará que otras personas le dirán qué partes necesitan pulido; hay muchas posibilidades de que lo pulen por ti.

Answer 3

Por lo que vale, creo que es una gran idea.

Pero, lo que es más importante, has elegido un proyecto (en mi opinión) que sin dudas mejorará la construcción de tu código y las chuletas de diseño. A menudo es bastante difícil encontrar proyectos que agreguen valor mientras mejoran sus habilidades.

Al menos complételo para sus necesidades iniciales y luego ábralo. ¡Cualquier cosa después de eso es una bonificación!

Answer 4

Si bien creo que la idea es intrigante y podría ser útil, no estoy seguro de qué valor a largo plazo pueda contener. Dado los avances considerables con EF v4 recientemente, incluyendo cosas como Code-Only, verdadero soporte de POCO, etc., lograr lo que está hablando no es tan difícil con EF. Soy un verdadero creyente en Code-Only estos días, ya que es simple, potente y, lo mejor de todo, comprobado en tiempo de verificación.

La idea de apoyar cualquier tipo de tienda de datos es intrigante, y algo que vale la pena investigar. Sin embargo, creo que podría ser más útil y llegar a un público considerablemente más amplio si implementa proveedores de tiendas para EF v4, en lugar de tratar de reinventar la rueda en la que Microsoft ha pasado años. Con frecuencia, los proyectos pequeños crecen ... y cosas como la puesta en común, la seguridad de los hilos, el soporte de LINQ / IQueryable, etc. se vuelven más importantes ... poco a poco, con el tiempo.

Al desarrollar proveedores de tiendas de datos EF para cosas como SqLite, MongoDB, archivos Xml o archivos planos, etc., se suman a las capacidades de un marco existente, familiar y accesible, sin que las personas tengan que aprender una más.