Étant donné un projet (en cours) qui implémente une architecture à deux niveaux avec une couche de gestion sur-couche bien séparée, suivant le generic DAO architecture as pioneered by Bill McCafferty on CodeProject typique et expliqué brièvement au chapitre 10 de NHibernate in Action.Quelles sont les approches recommandées pour migrer de NHibernate à deux niveaux à trois niveaux avec SOA (Microsoft CRM)?
Ce projet doit être déplacé pour effectuer les opérations CRUD et la logique métier via Microsoft CRM en tant que niveau intermédiaire à l'aide de services Web. Les objets et méthodes personnalisés sont définis dans le CRM pour imiter la situation actuelle.
Je ne pense pas que ce soit une bonne idée de commencer à déplacer le POCO d'avant en arrière de la même manière que nous avions l'habitude de faire. En outre, les fonctionnalités de chargement différé, de mise en cache et de concurrence doivent toutes être traitées différemment. Considérant que nous devons minimiser les appels entre couche intermédiaire et couche de présentation apporter un autre défi.
La mise en œuvre de DTO semble la bonne cause d'action, mais nécessite un long chemin (plus un chemin d'apprentissage pour l'équipe). J'ai déjà réalisé des projets SOA, mais maintenant je cherche le chemin de moindre résistance. Pouvons-nous continuer à utiliser NHibernate, même si la connexion directe à la base de données ne sera pas une option? Devrons-nous repenser la conception, ou les entités déconnectées, introduites dans .NET 4.0 peut-être une option? Comment peut-il devenir indolore?
comment pouvez-vous utiliser NHibernate quand aucun accès direct à DB est possible? –
@afsharm, eh bien, c'est la question ici. NH travaille avec des connecteurs et techniquement, vous devriez pouvoir brancher un traducteur pour HSQL à FetchXML. Considérant XRM (comme mentionné par Josh) est une couche utilisant ADO.NET, il pourrait être possible de combiner les deux. Que ce soit aussi faisable est une autre question. – Abel