De bons principes de programmation en utilisant EF/Code First/Repository Pattern/Table Per Type (TPT) ?

Question

Simple curiosité.

Disons que j'ai une entité Base et que j'en dérive environ 10 entités enfants différentes en utilisant la méthode Table Per Type. Je dispose également d'un référentiel générique capable de récupérer les données de chacune de ces entités filles. Je veux finalement mapper chacune des entités enfants à un modèle de vue séparé et lier chacun des modèles de vue à sa propre grille (JqGrid) sur mon site web, chaque grille ayant ses propres méthodes de création, de lecture, de mise à jour et de suppression. Je peux faire tout cela, mais je ne suis pas sûr de la bonne façon de procéder tout en gardant un minimum de code.

Actuellement, j'ai défini tous les champs (de l'entité mère et de l'entité fille) dans chacun de mes modèles de vue. Est-il préférable d'avoir un modèle de vue "parent" et d'en dériver les modèles de vue enfants afin d'imiter la structure d'héritage des entités ? Je ne le pense pas....avoir un héritage dans les modèles de vue n'a pas beaucoup de sens pour moi.

De plus, je ne souhaite pas dupliquer les opérations CRUD pour chaque grille. Est-ce considéré comme une bonne pratique ? Est-ce que chaque modèle de vue devrait avoir son propre ensemble d'opérations CRUD dans ce cas ?

Prenons l'exemple de "Read". Je renvoie des données JSON basées sur le champ ID (clé) du modèle de vue pour chaque grille. Et puisque toutes les grilles auront cette colonne ID (qui fait partie de l'entité mère), dois-je avoir une seule fonction qui s'occupe de cela pour toutes les grilles ? Dois-je utiliser des réflexions ? Dois-je utiliser les propriétés polymorphes des entités parent/enfant ?

Ou est-il préférable de séparer ces opérations pour chaque grille ?

Hmmm

Answer 1

Cela dépend.

En plus de toutes les règles, je dirais : Restez simple et ne vous répétez pas.

Quelques commentaires :

Disons que j'ai une entité Base et que je dérive environ 10 dif différentes à l'aide de la méthode Table Per Type.

Vous êtes conscient de la faible performance (au moins pour EF < 5) de TPT, n'est-ce pas ? C'est quelque chose à garder à l'esprit, surtout si les tables peuvent être grandes ou si vous avez une hiérarchie d'héritage profonde (entités dérivées d'entités dérivées..., etc.).

Je souhaite éventuellement mapper chacune des entités enfants. modèle

C'est à mon avis une bonne idée, ne serait-ce que pour les règles de validation différentes que vous pourriez appliquer aux ViewModels pour chaque entité dérivée.

Est-il préférable d'avoir un modèle de vue "parent" et de dériver ensuite le modèle de vue "enfant" ? à partir de celui-ci afin d'imiter la structure d'héritage du modèle de vue entités ?

Pour imiter l'héritage des entités n'est pas une raison à mon avis. Mais si vous avez par exemple des règles de validation de vue sur les propriétés du modèle de base et qu'elles s'appliquent à toutes les entités dérivées, pourquoi ne pas conserver ces règles en un seul endroit - comme un ViewModel de base. Sinon, il faudrait les répéter dans chaque ViewModel dérivé.

Chaque modèle de vue doit-il avoir son propre ensemble d'opérations CRUD ? dans ce cas ?

Si les entités dérivées sont "plates" (elles n'ont que des propriétés scalaires et aucune propriété de navigation), vous n'aurez besoin que de quelque chose comme.. :

Read: context.BaseEntities.OfType<T>().Where(...)...
Add: context.BaseEntities.Add(T entity);
Delete: context.BaseEntities.Remove(T entity);
Update: context.Entry(object o).State = EntityState.Modified;

Toutes ces méthodes fonctionnent pour les entités de base et les entités dérivées. Pourquoi voudriez-vous créer de telles méthodes pour chaque entité séparément ? Vous pourriez avoir besoin de méthodes distinctes dans des situations plus complexes, par exemple si l'entité dérivée numéro 7 possède une propriété de navigation vers une autre entité et que votre vue pour cette entité permet de modifier les relations avec l'autre entité. Tout dépend donc de la situation. Je ne commencerais pas par dupliquer des méthodes qui font toutes la même chose, je préfèrerais refactoriser plus tard lorsque je verrais que j'ai besoin d'un traitement spécial (sauf peut-être lorsque vous pouvez prévoir dès le départ qu'un traitement spécial est attendu à un moment donné au cours de l'évolution du projet).

Je renvoie essentiellement des données JSON basées sur l'ID ( pour chaque grille. Et puisque toutes les grilles auront cette colonne ID (qui fait partie de l'entité parentale), dois-je avoir une seule fonction qui qui s'occupe de cela pour toutes les grilles ?

Du côté du référentiel/service, oui, si seules les propriétés scalaires sont chargées pour chaque entité dérivée. Si vous avez besoin de propriétés de navigation pour l'entité dérivée 7, vous pouvez avoir besoin de quelque chose de spécial (peut-être un fichier Include ). La projection des données dans les ViewModels peut être spécifique à chaque entité parce que vous avez des ViewModels distincts pour chaque entité.

Dois-je utiliser des reflets ?

WTF ? Pourquoi cela ? Mieux vaut ne pas le faire.

Dois-je utiliser les propriétés polymorphes de t ?

? ?? (<- ceci est supposé être un Emoticon "Confus")