ADO.NET Entity Data Model : DBContext

Version imprimable

27/07/2015, 09h48
lsylvain

ADO.NET Entity Data Model : DBContext

Bonjour à tous,

Je viens pour avoir vos avis.

Je suis sous Visual studio 2013 et je suis en train de réaliser une API Full Web MVC Razor, pour récupérer les données issues de la base de données SQL Server, j'ai créé un projet ADO.NET Entity Data Model qui a créé tout ce qui me fallait (le DbContext notamment) pour récupérer ce dont j'avais besoin. Cependant, suite à l'évolution de mon projet l'une de mes tables contient une colonne SQL_Variant et une autre table utilise le système de FileStream. Et apparemment "ADO.NET Entity Data Model" ne prend pas en charge les SQL_Variant.

Selon vous le dbcontext peut me suffire pour réaliser des opérations d'ajout, de modification de données dans ma base de données SQL server. Et notamment sur les données type SQl_Variant et les opérations sur le FIleStream ? Si oui avais des exemples ou une bonne documentation sur ce sujet ? Sinon qu'es que je peux utiliser pour réaliser tout ce dont j'ai besoin?

Merci à tous pour votre aide ;)
27/07/2015, 10h45
DotNetMatt
En règle générale il faut éviter d'utiliser ce "type" de données (si on peut parler de type...). C'est un peu le fourre-tout que tu utilises quand ton schéma de base de données a été codé avec les pieds et que tu n'as pas d'autre solution.

Avec EF tu as 2 possibilités :
1. Implémenter un workaround qui te permettra juste de lire les données (pas d'écriture): Reading sql_variant in Entity Framework. Avec EF7 la gestion des mappings types est plus souple, donc il y a peut-être d'autres facons de procéder.
2. Créer une vue dans SQL Server qui renverra les données typées correctement. Ensuite il suffit de référencer cette vue dans EF.
En ce qui concerne la seconde option, dans ce cas autant revoir ton schéma et ne pas utiliser ce type. Ca revient un peu à n'utiliser que le type System.Object en C#... Microsoft indique que le support de sql_variant est dans le backlog mais pour le moment aucun support réel n'existe.

Pour FileStream tu peux utiliser EF pour lire la table de manière classique. Pour les opérations d'écriture (et aussi de lecture), tu peux regarder du côté de la classe SqlFileStream.
27/07/2015, 15h53
lsylvain

Tout d'abord, un grand merci pour ta réponse DotNetMatt.

Le choix du SQL_Variant a été mûrement réfléchie. J'utilise "La technique des méta données" voir : http://sqlpro.developpez.com/cours/m...n/metadonnees/ . Comme vous pourrez le voir dans cet article, la personne utilise un char(32) afin que les rubriques à ajouter ne dépasse pas la longueur prévue dans le méta modèle. Hors dans mon cas 32 n'est vraiment pas suffisant, car je peux avoir à stocker des bits comme des 'uniqueidentifier'.

Et donc le SQL_Variant me permet de stocker tous ce dont j'ai besoin.

Le problème est quand j'utilise ADO.NET Entity Data Model qui me génère un DbContext, celui ne contient pas mon modèle qui stock les "valeurs" de mes métadatas (dans l'article cela correspond à la table "TR_CARACTERISTIQUE_CAR"). Car cette table ce retrouve mappé (à cause de LINQ je pense) et d'autre part ma colonne "Value" du "type" SQL_Variant à disparut (car non pris en charge).

Et donc je me demande si utiliser un DbContext est vraiment la solution ? Es que je peux désactiver complètement LINQ ?
27/07/2015, 16h49
DotNetMatt

Citation:

Envoyé par lsylvain

Le choix du SQL_Variant a été mûrement réfléchie. J'utilise "La technique des méta données" voir : http://sqlpro.developpez.com/cours/m...n/metadonnees/ . Comme vous pourrez le voir dans cet article, la personne utilise un char(32) afin que les rubriques à ajouter ne dépasse pas la longueur prévue dans le méta modèle. Hors dans mon cas 32 n'est vraiment pas suffisant, car je peux avoir à stocker des bits comme des 'uniqueidentifier'.

Ok, si c'est mûrement réfléchi et mesuré, rien à redire ;) Mais je préférais m'en assurer !

Citation:

Envoyé par lsylvain

Et donc je me demande si utiliser un DbContext est vraiment la solution ? Es que je peux désactiver complètement LINQ ?

En fait avec EF tout dépend ce que tu cherches à faire. Si tu dois juste lire, tu peux continuer à l'utiliser et regarder l'implémentation proposée dans le premier lien de ma première réponse. Tu peux aussi utiliser une vue qui va se charger de caster correctement et te renvoyer les données typées avec par exemple tous les Int32 dans une colonne, tous les GUID dans une autre, etc.

Si par contre tu dois lire et écrire, alors la problématique est différente et sera plus complexe à résoudre je pense. Le mieux dans ce cas c'est probablement d'avoir une couche d'accès aux données "manuelle" où tu vas pouvoir tout gérer à la main.

Si tu dois absolument garder EF, je ne connais pas assez les méandres de cette techno pour t'aider plus malheureusement... Enfin désactiver LinQ n'est pas possible, car ca fait partie du .NET Framework.

[EDIT] Une idée peut-être à explorer : utiliser des procédures stockées. Tu dois pouvoir déclarer un paramètre par exemple sous forme de char(x) et ensuite utiliser une UDF pour convertir ca en SQL_VARIANT.
28/07/2015, 10h30
lsylvain

Citation:

Envoyé par DotNetMatt

Si par contre tu dois lire et écrire, alors la problématique est différente et sera plus complexe à résoudre je pense. Le mieux dans ce cas c'est probablement d'avoir une couche d'accès aux données "manuelle" où tu vas pouvoir tout gérer à la main.

Je pense en effet que c'est la meilleur solution. Et donc dernière question : Qu'elle est la meilleur méthode pour réaliser la couche d’accès aux données, afin de récupérer les données dans SQL server et de les transmettre à la couche supérieur ?
Sachant que les données devront être affichées dans une Page Web Html+Razor et par la suite soumis (via Ajax.BeginForm()) afin que ces mêmes données soient mises à jour dans la BDD.
Vraiment merci pour ton aide ;)
28/07/2015, 10h59
DotNetMatt
Pour la DAL j'utilise souvent l'exemple publié par Rudy Lacovara. Cette série de 3 articles a été traduite en Francais par notre ami Hervé (rvt26) :
Pour garder un découpage conventionnel, cette DAL doit juste te permettre de faire tes opérations CRUD en utilisant les DTO (Data Transfert Object - objets qui transitent entre les couches).
Ensuite par-dessus cette DAL, tu peux rajouter une couche de Business Logic (BLL = Business Logic Layer), dans laquelle tu peux manipuler tes DTO et appliquer tes règles métier.
Enfin, au-dessus de cette BLL tu as ton site MVC. La BLL est interrogée par tes Controllers uniquement elle récupère le DTO, le mappe à un Model/ViewModel puis envoie tout cela à ta vue.

Si besoin, il est possible d'ajouter une couche de validation entre la BLL et le site MVC, ou bien directement au sein de la BLL...
31/07/2015, 11h42
lsylvain

Je te remercie DotNetMatt je vais me renseigner un peu plus sur les autres méthodes possibles pour réaliser ma DAL histoire d'être sur de partir sur ce que tu m'a donné !
Encore Merci !!!