c# in memory database



Mon idée d'une bibliothèque de persistance d'objets est-elle utile? (3)

Ben, je pense que c'est génial. À tout le moins, postez-le sur CodePlex et partagez-le avec le reste du monde. Je suis tout à fait sûr qu'il existe des développeurs qui peuvent utiliser un framework de persistance d'objet (ou l'aider à le peaufiner).

Tout d'abord, je m'excuse si ce n'est pas un endroit approprié pour poser cette question, mais je n'étais pas vraiment sûr d'où d'autre pour obtenir des commentaires.

J'ai créé une version antérieure d'une bibliothèque de persistance d'objet .NET. Ses caractéristiques sont:

  • Une interface très simple pour la persistance des POCO.
  • La principale chose: support pour à peu près tous les supports de stockage imaginables. Ce serait tout des fichiers texte sur le système de fichiers local, aux systèmes embarqués comme SQLite, n'importe quel serveur SQL standard (MySQL, postgres, Oracle, SQL Server, etc.), aux bases de données NoSQL (Mongo, Couch, Redis, etc.). Les pilotes peuvent être écrits pour presque n'importe quoi, ainsi, par exemple, vous pouvez facilement écrire un pilote où le magasin de sauvegarde pourrait être un service web.

Quand j'ai eu cette idée, j'étais convaincu que c'était vraiment génial. J'ai rapidement créé un prototype initial. Maintenant, je suis à la «partie dure» où je discute des issues comme la mise en commun de connexion, la sûreté de fil, et débattre si essayer d'appuyer IQueryable pour LINQ, etc. Et je prends un regard plus dur si cela vaut la peine de développer cette bibliothèque au-delà de mes propres exigences pour cela.

Voici un exemple basique d'utilisation:

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

L'interface de recherche qui fonctionne maintenant ressemble à ceci:

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

Je travaille également sur une interface de requête alternative qui vous permet de passer quelque chose de très proche d'une clause SQL WHERE. Et évidemment, dans le monde NET, ce serait formidable de supporter les arbres IQueryable / expression.

Étant donné que la bibliothèque prend en charge de nombreux supports de stockage dotés de fonctionnalités disparates, elle utilise des attributs pour aider le système à optimiser l'utilisation de chaque pilote.

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

Tous les attributs sont facultatifs et concernent essentiellement les performances. Dans un cas simple, vous n'avez besoin d'aucun d'entre eux.

Dans un environnement SQL, le système prendra par défaut soin de créer des tables et des index pour vous, bien qu'il existe une option DbaSafe qui empêchera le système d'exécuter des DDL.

Il est également amusant de pouvoir migrer vos données d'un moteur SQL vers MongoDB dans une ligne de code, par exemple. Ou à un fichier zip. Et encore une fois.

OK, la question:

La question fondamentale est "Est-ce utile?" Cela vaut-il la peine de prendre le temps de vraiment peaufiner, de créer des liens entre les threads ou de se connecter, d'écrire une meilleure interface de requête et de télécharger quelque part?

  • Existe-t-il déjà une autre bibliothèque qui fait déjà quelque chose comme ceci, nommément, fournissant une interface unique qui fonctionne à travers plusieurs sources de données (au-delà de différentes variétés de SQL)?
  • Résout-t-il un problème qui doit être résolu ou est-ce que quelqu'un d'autre l'a déjà résolu?
  • Si je continue, comment allez-vous essayer de rendre votre projet visible?

Évidemment, cela ne remplace pas les ORM (et il peut coexister avec les ORM, et coexister avec votre serveur SQL traditionnel). Je suppose que ses cas d'utilisation principaux sont pour la persistance simple où un ORM est overkill, ou pour les scénarios de type NoSQL et où une interface de type magasin de documents est préférable.


Answer #1

Même si je pense que l'idée est intrigante et pourrait être utile, je ne suis pas certaine de la valeur à long terme qu'elle peut avoir. Compte tenu des avancées considérables réalisées récemment avec EF v4, y compris des éléments tels que le code uniquement, le véritable support POCO, etc., la réalisation de ce dont vous parlez n'est pas si difficile avec EF. Je suis un vrai croyant dans Code-Only ces jours-ci, car il est simple, puissant, et le meilleur de tous, à la compilation vérifiée.

L'idée de soutenir n'importe quel type de magasin de données est intrigante, et quelque chose qui mérite d'être étudié. Cependant, je pense que cela pourrait être plus utile, et atteindre un public beaucoup plus large, si vous implémentez des fournisseurs de magasins pour EF v4, plutôt que d'essayer de réinventer la roue que Microsoft a passé des années. Les petits projets se développent le plus souvent ... et des choses comme la mise en commun, la sécurité des threads, le support LINQ / IQueryable, etc. deviennent plus importants ... petit à petit, avec le temps.

En développant des fournisseurs de magasins de données EF pour des choses comme SqLite, MongoDB, des fichiers Xml ou des fichiers plats, vous ajoutez aux capacités d'un framework existant, familier et accessible, sans que les gens en apprennent un autre.


Answer #2

Pour ce que ça vaut je pense que c'est une bonne idée.

Mais plus important encore, vous avez choisi un projet (à mon avis) qui améliorera sans aucun doute la construction de votre code et la conception des côtelettes. Il est souvent assez difficile de trouver des projets qui ajoutent de la valeur tout en améliorant vos compétences.

Au moins le compléter à vos besoins initiaux et ensuite l'ouvrir. Rien après ça c'est un bonus!





object-persistence