Commutation stratégie d'accès aux données loin dans un projet?

Question

Dans un projet que nous avons mis en place la couche d'accès aux données (DAL) avec un concepteur visuel qui génère automatiquement beaucoup de code . (Dans notre cas: jeux de données et DataSetTableAdapters fortement typé dans .NET)

Cependant, en utilisant le contrôle de la source Je trouve gênant de modifier et d'ajouter de nouvelles choses à la DAL. Nous avons commencé à coder un nouvel accès de données en écrivant manuellement les instructions SQL (Dans notre cas: ADO.NET SqlCommands etc) qui me semble plus propre à modifier, et surtout pour voir les changements via le contrôle source.

Mais je suis aussi inquiet pour le mélange des méthodes d'accès aux données. Que suggérerais-tu? Stick avec la méthode de génération automatique, continuer à convertir en instructions SQL « manuel » lorsque des changements sont nécessaires, ou autre chose?

Edit: Inspiré par les belles réponses qui traitent du problème général de la commutation stratégie d'accès aux données, J'ai généralisé la formulation de la question.

La gestion des données de modèle n'est pas très orienté objet. Nous utilisons DataTables .NET au lieu des objets personnalisés.

Answer 1

Si le choix est entre la conversion à ADO manuel ou continuer à utiliser des jeux de données + adaptateur de table, je pense que vous êtes mieux de rester avec les ensembles de données. Vous obtenez gratuitement CRUD en l'utilisant, et donc moins de temps utilisé sur la création et le maintien sql qui ne donne pas de valeur.

Par la façon dont vous formulez votre question, il ne semble pas que vous allez pour une approche plus orientée objet non plus, ce qui pourrait être un argument pour aller loin de l'ensemble de données + approche adaptateur table.

Vous pouvez faire des recherches / prototypage dans le OU-Mapper + purs objets de domaine et, si vous avez une logique de plus en plus complexe à gérer. Il est moins efficace pour l'approche RAD bien. Je vérifier Linq 2 sql (si vous avez un schéma simple / structure de l'objet et sont heureux avec 1: 1 entre objet et une table) ou NHibernate si je vous étais. Entity Framework est pas assez mature. La prochaine version sera mieux, mais il est encore potentiellement une longue période à venir.

Answer 2

Oui, le bâton avec ce que vous avez et refactoring nécessaire et pratique. Je déteste d'être en désaccord avec les autres réponses, et compliquer les choses, mais en utilisant un autre cadre d'accès aux données vous peuvent être TRADING un mal de tête du système pour une autre. Allez avec vos bases avec lequel vous êtes à l'aise.

Answer 3

Aller à ADO.NET et de faire tout le travail DAL « nu » droite manuellement dans le code semble comme beaucoup d'efforts. Je recommande vivement regarder un OU-cartographe, comme ont été recommandés par d'autres (NHibernate, Subsonic etc.).

Si votre back-end dans SQL Server et vous êtes sur .NET 3.0 ou supérieur, vous pouvez aussi regarder dans Linq2SQL (les rumeurs de sa mort sont grandement exagérées) pour des scénarios plus simples (1: 1 cartographie à partir des tables de base de données à votre database- objets de la couche), ou Entity Framework pour des scénarios plus avancés (beaucoup de tables, beaucoup d'héritage d'objets dans votre modèle de domaine, des scénarios de cartographie complexes).

EF a reçu beaucoup de mauvaise réputation ces derniers temps, ce qui est justifié que partiellement, à mon humble avis, et la nouvelle version, EF v4 (en raison avec .NET 4.0 et VS 2010 quelque temps ce ou l'année prochaine) semble vraiment prometteur.

Marc

Answer 4

Si vous réécrivez complètement votre DAL alors peut-être vous devriez regarder dans un cadre de persistance comme Sprint.NET ou NHibernate .

Answer 5

... ou SubSonic Rob Conery :)

voir au moins les 3 vidéos que vous pouvez trouver dans la page du projet.

Answer 6

Le DAL est le plus souvent la plus grande partie au-dessus-ingénierie selon l'une quelconque application. Keep it simple et construire ce dont vous avez besoin maintenant ou anticipez raisonnablement besoin très bientôt. SqlCommand, SqlDataReader, etc. sont encore relativement abstraite par rapport aux écrous et boulons de connexion en fait, la lecture et l'écriture dans une base de données.

Cela dit, votre code sera plus lisible si vous utilisez une seule approche générale.