Conception de couche d'accès aux données dans l'application ASP.NET 3.5

Question

Je dois décider de la couche DATA Access d'une application Web de taille moyenne à exécuter sur l'intranet d'une entreprise. J'ai déjà travaillé avec CodeSmith et je l'ai trouvé utile mais il consomme beaucoup de temps de développement si le schéma de base de données sous-jacent change, je voudrais donc m'en débarrasser et m'essayer avec un nouveau DAL qui aiderait au développement rapide d'applications.

Veuillez partager votre opinion sur la technologie LINQ et le cadre ADO.Net Entity. Je n'ai jamais travaillé avec ces technologies et n'ai aucune idée si elles peuvent être utilisées avec succès pour les applications centrées sur les bases de données d'entreprise.

Veuillez suggérer d'autres technologies qui méritent d'être explorées.

-Sweta.

Answer 1

Les deux frameworks sont utiles, et si votre base de données est en grande partie statique, ils fonctionnent mieux.

Mon expérience a été d'écrire simplement le SQL, mais c'est parce que j'ai travaillé sur une application basée sur une base de données, donc les bases de données changent beaucoup. Avec n'importe quel ORM, vous capturerez le schéma dans le code source en utilisant un outil, puis vous interagirez avec ces classes et elles iront à la base de données. Vous voudrez peut-être essayer d'écrire des vues ou des procédures stockées pour extraire les tables de base de données réelles, de sorte que vous puissiez avoir quelque chose de plus statique à travailler. Cependant, j'aime bien DLINQ, car j'ai trouvé plus facile de faire certaines fonctionnalités, comme la pagination, que de le faire dans l'application, moi-même.

Cependant, je n'ai pas beaucoup fait avec ADO.NET.

Answer 2

Je pense que vous devriez utiliser Linq (pas LinqToSql), parce que Linq bascule. Je pense que vous devriez utiliser un ORM, en partie parce que vous avez besoin de quelque chose comme ça pour pouvoir utiliser Linq, et en partie parce que créer une couche de données sans ORM n'est pas une bonne façon de passer votre temps et votre budget.

Entity Framework n'a pas reçu de bonnes critiques en général, mais beaucoup de gens l'utilisent. Il change de manière significative dans Visual Studio 2010/.NET 4.0.

NHibernate est ce que la plupart des gens utilisent pour un ORM .NET. Il y a beaucoup d'options à choisir.

Voici, je pense, un bon morceau d'opinion sur l'utilisation des procédures stockées:

Stored procedures are bad, m'kay?

Si vous décidez d'utiliser un ORM, vous voulez probablement regarder cette question et les autres questions comme il:

NHibernate, Entity Framework, active records or linq2sql