Sans entrer dans une discussion sur la question de savoir si la logique commerciale doit être dans la base de données ou à la couche d'application, car elle a été couverte ailleurs .
Mon équipe traduit les lignes Nous avons déjà trouvé un outil merveilleux pour aider à convertir les requêtes ad-hoc, SmartCode , mais cela ne crée que du code basé sur des tables et des vues. Nous recherchons un outil pour aider à convertir les procédures stockées.
Les procédures stockées ont la plus grande partie de la logique commerciale que nous souhaitons migrer vers la couche d'application. Nous vous demandons s'il existe des outils pour convertir les procédures stockées en code C #.
En supposant qu'il n'y en ait aucun, quel serait le meilleur endroit pour commencer si nous développons l'outil interne / open source. Y a-t-il un autre système similaire avec des objectifs similaires pouvant être utilisés comme lieu de départ?
Mise à jour acceptée de réponse:
J'ai sélectionné la réponse de Scope-Creep, car il semble être la meilleure méthode de mise en œuvre du problème présenté dans la question. Pour ceux qui traitent de ce même problème, je recommande avec précision la réponse d'Adam, car il a fortement préconisé l'utilisation d'un outil et fournit une forte justification. Il a également fourni la plus grande interaction avec cette question et avait la réponse la plus élueillonnée.
Merci à tous pour votre aide et votre dialogue.
5 Réponses :
Je ne crois pas qu'il y ait des convertisseurs pour SQL à C #.
En ce qui concerne l'approche de la création d'un tel outil, je dirais d'abord, ne ... votre besoin de votre entreprise sonne comme si elle est d'obtenir la logique dans C #.
Selon l'état de l'application, vous pouvez le faire à bien des égards: une SPROC à la fois; entités logiques à la fois (toutes les logiques du client, etc.); tout le porc; Agile-ISH où vous laissez les Sprats seuls pour le moment et appelez-les directement en eux de C #, puis prenez lentement l'une des approches préalables - vous laissant toujours une application fonctionnelle.
Question chargée vraiment: -)
J'ai personnellement essayer d'abord de le faire fonctionner dans C # droit appelant dans les Sprates. Ensuite, prenez des entités logiques, comme vous le trouverez, ils peuvent faire référence à d'autres SCROC. Faire une SPRO à la fois fragmentera votre logique C # pendant le développement et ajoutera des frais généraux supplémentaires à la création de classes d'affaires.
La force d'un modèle de domaine C # est la limite claire de la responsabilité et le regroupement de comportement dans vos entités logiques - prenant donc une SPTP à la fois, vous ne verrez pas la plus grande image. En utilisant un convertisseur, il se terminera par un code illisible et ingérable que vous devez ensuite apprendre - quelque chose dont vous n'avez pas besoin de faire si vous le créez en premier lieu.
Donc, ma conclusion, s'il y en a un, est de vous faire sauver le temps à l'avenir et de prendre cela comme une opportunité de redéfinir votre couche d'affaires - comme vous avez probablement des connaissances et une expérience du comportement de production du système à l'état sauvage, La conversion peut donc prendre en compte les enseignements tirés.
Mise à jour: Il s'avère que vous avez des options d'outils pour la conversion. La seule chose que je vais dire à cette approche est la suivante: le code résultant ne sera pas assez . Vous avez le bénéfice que votre SQL actuel est comprise par l'équipe de développement - ils connaissent le code. Un générateur de code va produire 100% nouveau code que personne ne sait . Courbe d'apprentissage ... Comme vous allez avoir besoin Si vous décidez d'utiliser l'outil, je ne peux que suggérer de casser la conversion en très petites pièces (probablement le plus petit va être un script (ou peut-être même un lot dans un script)). Lorsque vous avez un petit ensemble de résultats de conversion, intégrez-la dans l'application et transmettez-la à travers un processus d'examen.
Totalement d'accord ceci ... Trop de variables pour tirer où des clauses dans le code C # et créer les objets et l'architecture appropriés.
J'ai fait d'autres analyses et découvert cela comporte plus de 100 000 lignes de PL / SQL. Seriez-vous toujours d'accord pour faire celui-ci à la fois? Je pense que cela prendrait des mois de travaux de conversion et serait sujette de bug.
@LUCAS Ce serait également sous forme de bugs à l'aide d'un outil de conversion. Je dirais pour une telle base de code, vous devez examiner si elle est financièrement réalisable de migrer le code. Je suggérerais la mi-chemin - Obtenez C # Communiquer et utiliser votre SQL tel qu'il se trouve, puis lorsque vous effectuez des itérations de projet, assurez-vous que certains travaux de conversion reçoivent une priorité. Il n'y a pas de réponse facile, ça va être un slog ... cela ressemble à la majeure partie de la logique est dans SQL, donc une conversion sur C # va probablement être semblable à réécrire toute quelle que soit l'application complète, de sorte que les dépister sont donc les frais généraux. va être énorme.
@LUCAS Avis sur les commentaires à votre question, il semble que l'IRA puisse vous aider avec un outil. Si vous parvenez à obtenir quelque chose de travail à cet égard, postez-vous et partagez la bonté - je serais curieux de voir comment une conversion SQL à C # se produit.
J'espère que cela aide:
Si vous faites NHibernate avec Oracle, vous souhaitez lire le blog de Devio.
llblgen pro fonctionnalité:
Je n'ai pu trouver rien qui convertit le PL / SQL directement à C #, mais trouvé quelques produits qui convertissent PL / SQL en Java (que vous pouvez ensuite convertir en C #).
swissql: http: //www.swissql .Com / Produits / Oracle-To-Java / Oracle-To-Java.html convertit Java en C #
Stackoverflow Réponse: outil pour convertir Java en code C # < / p>
Exodus: http://www.ciphersofinc.com/products/ plsql-to-java-conversions-outils.html
Indirection, mais une réponse techniquement correcte - je déteste vraiment voir le C # résultant si ...
@Mien, cela se rapproche certainement, bien que je suis d'accord avec Adam, s'il y a eu de nombreuses couches de conversion, quelle quantité de la logique originale serait en place et à quel point cela serait-il maintenu ... je vais courir tests et rapporter.
Un moyen de le faire est d'utiliser ANTLR V3, de construire une langue spécifique de domaine. ANTLR V3 a un PL / SQL PL / SQL grammer pour 10g, 11g à Construire un lexer / analyseur pour PL / SQL, ce qui serait la première étape. Un générateur de code C # 3.0 est disponible pour le backend pour C # 3.0. Le générateur de code est toujours en cours de développement, mais c'est dans un état avancé.
Je ne sais pas combien de travail s'ensuivrait avec cette approche, mais je pense certainement que cela coûterait moins cher que la traduction manuelle.
Il y a un livre disponible appelé Référence AntLR définitive: Domaine de bâtiments -Lagils spécifiques . Je sais que vous suggérez un livre à ce moment-là, lorsque vous avez un tas de travail à faire, c'est crasse, mais cela vous donnera une idée du processus impliqué et peut-être suffisamment pour coûter la conversion.
Il a déjà été une question sur la pile débordement: écrire un traducteur de langue qui Liens vers le projet ANTLR MORPH, qui est un sous-projet pour définir un mécanisme de traduction commune. DOC et FAQ Expliquez comment cela fonctionne. Essentiellement, un script est utilisé pour définir un mécanisme de traduction. Il est encore en début d'étapes, mais pourrait valoir un aspect, car il s'agit d'un scénario courant qui n'a pas encore été abordé.
Cet exemple explique comment créer des transformations d'arbres, c'est-à-dire marcher l'arborescence à la sortie du code traduit, trouvé ici: Traductions d'arbres , avec Documentation ANTLR associée: Construction des arbres
Trouver le bon agent compilateur serait la clé du succès. J'ai examiné certains sites et leurs ingénieurs compilateurs sont disponibles. Je pense que ce serait moins cher en utilisant 1 ou 2 ingénieurs compilateurs pendant plus de 3 mois, de faire le travail que de plus de 4 ingénieurs et plus de plus de 3 mois pour la traduction manuelle. Au Royaume-Uni, vous recherchez un entrepreneur pour le faire.
espère que cela aide Bob.
EDIT: 01/08
J'ai trouvé un autre livre qui discute de créer des traducteurs de langue, trouvé ici, appelé Modèles de mise en œuvre de la langue
@ Scope-Creep Y a-t-il des exemples de projets pour travailler? Si oui, pourriez-vous me signaler à eux?
Même avec de bonnes infrastructures, la construction d'un bon traducteur prend beaucoup de temps. En EssenSense, vous devez le faire pour écrire des règles de traduction pour chaque idiome de base de la source de base et pour les idiomes de langue source d'intérêt particulier, et obtenir tous ces éléments de travailler ensemble. Mon équipe a de l'expérience en faisant cela et pour un SLOC 100K, vous êtes susceptible de voir la plupart des éléments de langue PLSQL. Je suppose que c'est qu'un très bon ingénieur pourrait y accomplir dans un an. 3 ingénieurs ne réussiront pas dans 4 mois. Je crois en la traduction automatisée; Mais la balance doit avoir raison.
Basé sur l'entrée de la portée-Creep, Adam et Ira-Baxter. Surtout, concernant faire des choses dans une mode de taille, des frontières claires de responsabilité et de regroupement de comportement
Une seule solution serait d'étendre l'outil SmartCode, qui génère déjà des entités agréables à travailler avec et puisqu'elle est open-source:
pensées?
Je ne peux pas commenter trop spécifiquement, mais les projets open source ont souvent des bases de code étranges. Vous devrez développer l'outil de votre dos et testez-le - essentiellement, le coût total de la propriété va être important. En outre, il n'ya aucune garantie qu'il peut être fabriqué dans ce dont vous avez besoin. Je suggérerais de prendre un petit sous-ensemble de votre logique d'application afin de faire une preuve de concept de cet outil SmartCode avant de vous engager.
Mais si vous pouvez le faire faire ce dont vous avez besoin, il n'ya rien de mal à cette approche - mais mettez le responsable de la gestion de projet et remettez en question combien de temps cela prendra par rapport à une réécriture. Ce dernier, vous pouvez commencer tout de suite et vous ne perdez pas l'expertise que vous avez déjà sur le SQL. Un nouvel outil est un projet totalement différent.
Combien de code avez-vous dans les procédures stockées? Si vous convertissez tout à la main, combien de temps pensez-vous que cela prendra?
Des milliers de lignes. À partir d'une analyse cassée, une grande partie du code est similaire, juste particulière à la table en question. La majeure partie du code "similaire", que j'estime être de 60 à 70% est autour des problèmes de chaîne NULL / vides et filtrage de la suppression programmable.
J'estime qu'il faudrait plusieurs mois pour convertir le code à la main, c'est pourquoi je envisage d'utiliser ou de créer un outil pour le faire.
Si ses milliers de lignes, il est peu probable que vous soyez capable de créer un outil avec moins d'effort que nécessaire pour la convertir. Si vous parlez de lignes de 100 000 lignes, un outil automatisé pourrait être une victoire sérieuse. Entre entre ... c'est un pari, surtout si vous n'avez pas d'expérience en construction de tels outils.
Si vous êtes intéressé par un outil pouvant analyser PLSQL et que vous pourriez être la base d'un générateur de code C #, vérifiez mon BIO. Au-dessus des mises en garde s'appliquent toujours.
C'est au-dessus de 100 000 lignes et je conviens qu'un outil serait une victoire sérieuse, c'est pourquoi j'ai offert une prime.
L'outil devra probablement être personnalisé ... J'ai construit des outils / processus relativement similaires dans le passé ... La plupart des processus étaient simplement du crud de base qui ont suivi un modèle très similaire, nous avons donc pu convertir automatiquement la plupart des d'eux. Cependant, tout ce qui avait une logique avancée (rechercher des recherches, effectuer des insertions d'addition, des suppressions, etc.) est beaucoup plus difficile. Une façon de gérer est de classer les types de Procs que vous avez, puis de créer des outils pour les plus grandes catégories. Juste hors de curiosité - pourquoi voulez-vous déplacer la logique commerciale de la base de données?