3 couches et connection string

Version imprimable

13/12/2009, 14h53
zax-tfh

3 couches et connection string

Bonjour à tous,

Dans le cadre d'un projet en 3 couches (DAL, BLL, UIL) et sachant que la DAL se base sur du LinqToSQL, comment et où stockez vous la connection string (et surtout comment faites vous niveau references et compagnie) ?
Pensez a prendre en considération un point : vous avez changé le gestionnaire de profils et d'authentification (donc vous n'utilisez pas AspNetSqlProvider), votre appli ne se base donc pas sur une base de données créée par défaut (ASPNETDB) mais sur la meme base que celle utilisée pour vos données.
13/12/2009, 18h49
Immobilis

Salut,

Web.Config. Tu peux avoir plusieurs chaines de connexions.

A+
13/12/2009, 20h43
zax-tfh

Hum oui, je me doute que dans le web.config tu peux avoir plusieurs connection strings...
Mais si je reprend ton schéma en 4 couches posté dans un autre topic (pas tres lointain) tu as

1) UI (Acces à la base pour membership, profiles, roles)
2) BLL
3) DAL (Acces à la base pour les données BO)
4) BO

1) Reference 2 et 4
2) Reference 3 et 4
3) reference 4
4) ne reference rien

tu vois que dans la couche 1 et la couche 3 tu as besoin de spécifier une connection string.

Maintenant la question que je me posais c'est :
Faut il mettre une connection string dans chacune de ces couches ou bien faut-il en avoir une dans une des couches et ensuite faire pointer les couches 1 et 3 sur cette connection string.

Dans le premier cas, pas de probleme, je pense que ca se fait facilement
Dans le second cas (celui qui est à l'origine de mon post), je ne vois pas trop comment on ferait.
Bref, ma réelle question est un peu plus générale que ca :

-> Que faites vous en général au niveau de la connectionstring pour une configuration en 3 ou 4 couches ?

Et pendant que je t'ai sur le coup Immobilis, mon cas est un peu particulier car j'utilise LinqToSQL qui me génere automatiquement mes BO, donc la couche 3 et 4 ne font finalement qu'une seule couche. Qu'en penses tu ? as tu un avis sur le sujet ? enfin le fait que je doive reference la DAL dans l'UI te parait-il mauvais ?

Merci
13/12/2009, 22h23
Immobilis

Citation:

Envoyé par zax-tfh

tu vois que dans la couche 1 et la couche 3 tu as besoin de spécifier une connection string.

1 n'est pas une couche mais un tier. Objectivement 1 se fiche des chaines de connection puisqu'il n'est pas sensé accéder aux données.

Citation:

Envoyé par zax-tfh

-> Que faites vous en général au niveau de la connectionstring pour une configuration en 3 ou 4 couches ?

Et pendant que je t'ai sur le coup Immobilis, mon cas est un peu particulier car j'utilise LinqToSQL qui me génere automatiquement mes BO, donc la couche 3 et 4 ne font finalement qu'une seule couche. Qu'en penses tu ? as tu un avis sur le sujet ? enfin le fait que je doive reference la DAL dans l'UI te parait-il mauvais ?

L'accès aux chaines de connexions se fait par "ConfigurationManager" qui est indépendant de l'interface. Tu peux donc y faire appel dans n'importe quelle couche.

Cependant, pour ma part, ma bll et ma dal héritent d'une classe de base abstraite dans laquelle se trouve un constructeur et des propriétés qui me permettent de faire passer un objet portant la chaine de connection et le fournisseur de données. Cela me permet de changer de base de données à l'execution de mon code. Ce peut donc être l'IU ou la bll qui determine la base de données dans laquelle aller chercher les données*. L'objet traverse toutes les couches pour atteindre la dal. Ensuite, j'ai un objet de connection et de méthodes d'accès aux données (ExecuteReader, ExecuteNonQuery, ExecuteDataSet, ...). La dal présente principalement les données du CRUD.

Pour ce qui est de LINQ to SQL, que je commence à aborder, j'ai de plus en plus d'aprioris. J'ai fait quelques tests et franchement c'est nettement plus lent à la lecture: http://www.developpez.net/forums/d84...-text-lerreur/

Enfin, en utilisant LINQ tu es effectivement obligé de rompre le schéma en couches. C'est le DataContext qui determine le modèle. Ce n'est ni bien ni mal, c'est différent et surtout c'est un choix. J'ai tout de même quelques reserves sur un système qui génère automatiquement des classes... Un modèle "à l'ancienne" pésente l'avantage de ne pas être dépendant de la source de données. Si tu décide de changer la dal et de n'utiliser que des web services par exemple le modèle n'est plus utilisable. Laurent Jordi en parle dans sa réponse dans cette discussion. La probabilité de changer de base de données n'est finalement pas si faible... ;)

A+

* C'est sensé répondre à un besoin de répartition de charge sur deux bases de données, l'une étant la copie de l'autre.
14/12/2009, 00h18
zax-tfh

Re !

Merci beaucoup pour ta réponse ! bon elle me souleve tout un tas de remises en question (en meme temps c'est normal je débute l'ASP.Net, le dev en tiers/couches et les designs patterns).

Je viens de lire les topics que tu m'as donné (ainsi que les liens connexes).
Bon déjà ça me fait plaisir de voir que mélanger MVC et n-tiers = pas cool... Je comprenais pas pourquoi je galèrais, mais je comprend mieux maintenant (et me conforte sur le fait d'avoir laissé de coté ASP.Net MVC pour le moment).

Pour ce qui est de la structure globale du projet, j'aimerai vraiment utiliser celle que tu décris en 4 couches dans ton schéma. Elle est pour moi celle qui est la plus réutilisable.

Maintenant ma problématique est la suivante : pisser de la ligne, c'est bien mais il y a pas mal d'outils (EF, LINQ, NHibernate...) qui permettent d'accélerer les temps de développement.
LINQ étant à la ramasse d'après test tests, EF étant tout comme LINQ trop lié aux BO et donc ne permet pas d'avoir de DTO au sens que tu l'utilise, à priori NHibernate serait un compromis interessant (maintenant je ne maitrise pas la bete donc je ne connais pas les tenants et aboutissants).

Que me conseillerais tu pour améliorer le process de codage de la DAL ? As tu un ORM de prédilection ? ou bien préferes tu tout faire par toi meme ?
Edit : j'ai bien vu que tu utilises un objet pour executer tes requetes, mais je serais curieux de voir comment tu l'as réaliser car j'avais fait par le passé une classe me permettant d'éxecuter mes requetes sql mais bon fallait tout faire à la mano derriere, et niveau temps de developpement c'etait pas le must.

Edit2: j'allais oublier un dernier point ! Quand tu dis que la DAL ne présente que les opérations CRUD, que fais tu des opérations particulières ? dans le genre je veux tel ligne avec tel parametre et tel autre, enfin les requetes un peu plus poussées que les simples CRUD quoi. Tu les places où celles ci ?

Merci pour tes conseils en tout cas, je sens que je vais bien avancer dans ma progression !
En tout cas, les recherches sont vraiment compliquées sur le sujet pour un débutant ! il y a tellement de façons de faire que je n'arrive pas à en faire le tri ! je cherche surtout une solution efficace et qui me permet d'etre suffisament libre pour changer une brique en cours de route.