2009-02-24 5 views
1

Disons que vous avez une base de données avec beaucoup de produits/clients/commandes et que la base de code (java/C#) contient toute la logique métier. Pendant la nuit, plusieurs lots sont nécessaires pour exporter des données vers des fichiers plats, puis les transférer vers un système propriétaire. ?Quelles sont les meilleures pratiques lors de l'exportation par lot à partir d'une application suivant DDD

Comment devons-nous faire « write-base de données en-un plat fichier Quelles sont les meilleures pratiques

Quelques réflexions:

  • nous pourrions créer une procédure stockée et utiliser f.ex ssis pour récupérer les données? Peut-être que nous pouvons le faire si nous avons une "batch-output-database-table" mais pas si nous devons faire la logique avant que le fichier est écrit?

  • nous pourrions faire toute la logique dans le code managé en utilisant les mêmes référentiels/logique métier que le reste de la domaine? (Cela pourrait être un processus lent par rapport à la solution de procédure stockée)

  • Et si la seule interface pour les services de domaine sont des services Web (ce qui pourrait prendre "long" temps pour chaque demande), sera le "meilleures pratiques " changement ?

Répondre

2

Personnellement, je préfère utiliser le code normal (géré) pour mettre en œuvre se nourrit au lieu de procs stockés, principalement parce que: 1) Il est généralement plus facile à l'interface avec l'autre système (même si elle est seulement lecteur partagé) 2) Il est facile de connecter tout ce dont vous avez besoin et de déboguer si quelque chose ne va pas 3) Vous pouvez réutiliser le même code que vous utilisez pour une logique métier normale (c'est avantageux même si vous référencez simplement les mêmes projets, etc.) 4) Souvent vous devez enrichir les données avec des informations provenant d'autres systèmes, ce qui est beaucoup plus facile à faire à partir du code managé. 5) Il est beaucoup plus facile de tester le code managé, d'avoir tous les tests unitaires, les builds automatisés, etc.

Je ne sais pas pourquoi il faut être aussi lent que de tout faire dans un process enregistré. Vous avez juste besoin d'écrire une bonne procédure stockée pour extraire les données dont vous avez besoin, et l'application C#/Java fera toutes les transformations, l'enrichissement, etc.

EDIT: Répondre au commentaire: Je ne pense pas que ce soit Il est possible de dire si vous devriez réutiliser les procs stockés existants, les modifier ou en créer de nouveaux. Je pense que c'est le coup de performance ou les changements nécessaires ne sont pas trop gros que je voudrais essayer d'utiliser un ensemble de procs, pour éviter la duplication de la logique. Mais si les différences sont substantielles, alors le coût de maintenance des procédures supplémentaires sera probablement inférieur à celui de la modification et de la libération des procédures existantes.

+0

tnx pour la réponse. suggéreriez-vous d'utiliser une méthode service/repository/sproc faite uniquement pour l'exportation donnée, ou d'utiliser les méthodes déjà présentes dans le domaine? -Si des méthodes de domaine sont utilisées, elles doivent parfois être modifiées pour donner de bonnes performances. Changements n'appartenant pas au domaine lui-même – ThorHalvor

0

Allez avec le code du référentiel que vous avez déjà. Faire quelques tests de performance et voir si elle répond à la perf. exigences. S'il y a une perf significative. problème qui peut être cloué à trop DB IO puis aller pour le sproc ou mettre en œuvre un référentiel d'exportation en vrac.

Questions connexes