Associer des agrégats définis par le consommateur (par exemple, des comptes SQL) avec des objets de modèle «purs»?

Question

Quelle est la meilleure pratique pour introduire des données personnalisées (généralement volatiles) dans les classes de modèle d'entité? Cela peut sembler une mauvaise pratique au départ, mais cela semble être un scénario assez courant. Dans notre récente application Web, nous avons développé un modèle approprié et, dans la plupart des cas, nous sommes en mesure de charger des entités de modèle. Mais il y a des cas où nous ne pouvons pas nous permettre de charger toute une hiérarchie d'entités; nous devons charger, par exemple, les résultats de quelques résultats de SQL COUNT ou éventuellement de certaines informations supplémentaires à côté (ou incorporées dans) des entités de modèle. Donc, en gros, les exigences et les conditions sont les suivantes:

1. C’est une application Web où 99,9999999999% des opérations sont des opérations de lecture.

2. Ils n'ont pas besoin de traiter ou de faire une logique métier compliquée. Nous avons juste besoin de transférer rapidement les données au format HTML.

3. Dans plusieurs cas de performances critiques, nous devons charger les résultats d'agrégats SQL qui ne correspondent à aucune propriété de modèle.

4. Nous avons besoin d'un moyen extensible d'introduire de nouvelles données personnalisées si nécessaire.

Comment résolvez-vous généralement ce problème sans trop travailler sur votre ORM (par exemple, les données brutes de la base de données)? Je suis sûr que cela a déjà été abordé à plusieurs reprises, mais je ne parviens pas à trouver une bonne requête Google pour trouver quelque chose d’utile.

Modifier : depuis que j'ai réalisé que la question n'était pas très bien formulée, j'ai décidé de la reformuler et de lancer un nouveau .

Answer 1

Si vous n'obtenez que des données relationnelles depuis et vers un navigateur, avec peu ou pas de comportement entre elles, cela ressemble à votre tentative de résoudre un problème relationnel avec un paradigme OO.

Je pourrais être enclin à renoncer totalement à l'approche orientée objet.

Mon équipe a récemment réécrit une application en demandant "Quelle est la chose la plus simple qui puisse fonctionner?" et "Quelle est la langue la plus proche du problème?". Notre nouvelle application, qui remplace une application OO, a fini par être 10 fois plus petite, plus rapide et moins chère.

Nous avons utilisé SQL, les procédures stockées, les bibliothèques XML sur le serveur de base de données, XSLT (pour obtenir le code HTML) et javascript.

Answer 2

OOP puriste comme moi irait au modèle de décorateur. http://en.wikipedia.org/wiki/Decorator_pattern

Mais le fait est que certaines personnes peuvent ne pas avoir besoin de la flexibilité qu’elle offre. De plus, la création de nouvelles classes pour chaque opération distincte peut sembler excessive, mais elle fournit une bonne vérification de type de compilation.

Answer 3

Selon moi, la meilleure pratique est que votre application consomme des données à l'aide du modèle Modèle de domaine . . Le modèle de domaine peut offrir des méthodes de logique métier pour effectuer le type de requêtes qui ont du sens et qui correspondent aux besoins de votre application.

Ceux-ci peuvent aller chercher " live " les résultats mappant directement sur les lignes de la base de données et pouvant donc être modifiés et "enregistrés".

Mais, en outre, le modèle de domaine peut fournir des méthodes permettant d'extraire des résultats en lecture seule trop complexes pour pouvoir être facilement sauvegardés dans la base de données. Cela inclut votre exemple de résultats de requête agrégés groupés, ainsi que les ensembles de résultats de requête joints, les expressions sous forme de colonnes, etc.

Le modèle de modèle de domaine offre un moyen de découpler la conception OO d'une application de la conception de la base de données physique.