[C#] MagicBuzz qui se remet au .NET, ça va être bô tiens !

MagicBuzz qui se remet au .NET, ça va être bô tiens ! [C#] - C#/.NET managed - Programmation

Marsh Posté le 06-01-2005 à 21:20:09    

Un certain nombre d'entre vous connais déjà mon jeu en ligne "BuzzLand" (http://buzz.manga-torii.com).
 
Après 9 mois d'inactivité, j'ai envie de le faire un peu évoluer.
Il est en ASP.
 
J'ai deux choix :
- Soit je continue en ASP, et ça va me lourder, mais au moins je saurai faire.
- Soit je profite de ma motivation exceptionnelle de 5 minutes pour passer à une version en .NET, mais ça va guère plus me motiver, et vu que je saurai pas faire, je vais venir vous emmerder toutes les 5 minutes pour répondre à des questions cons.
 
Allez, on va tenter le .NET (de toute façon, j'en ai besoin pour le boulot).
 
Alors...
 
Au taff, on a déjà fait quelques sites et .NET, et les personnes qui ont bossé dessus ont opté pour une architecture multi-projet.
Ca m'a l'air assez usine à gaz comme truc pour lancer le projet, mais pour la suite, ça semble en effet une très bonne solution.
 
En gros, ça donne ça :
- Projet "principal" (projet Web). Il contient les pages ASPX, les controles ASCX ainsi que quelques classes templates.
- Projet "common". C'est un projet de class contenant des classes fourre-tout, style des constantes, des fonctions de transformation de chaîne, de date, etc.
- Projet "facade". C'est un projet de class contenant des classes générant des objets "tous faits".
- Projet "business". C'est un projet de class contenant tous les objets métier, c'est à dire ceux qui vont contenir "l'intelligence" du site.
- Projet "database". C'est un projet de class contenant des objets permettant d'accéder à la base de données.
 
"principal" est lié à "common" et "facade".
"facade" est lié à "common" et "business".
"business" est lié à "common" et "database".
"database" est lié à "common".
"common" n'est lié à aucun autre projet.
 
En gros, de ce quej'ai compris, mettons que je veuille faire une page de recherche sur le site.
 
Dans "database", je vais créer un objet "searchTable" avec des méthodes permettant de charger des données des tables voulues, et qui renverrons un DataSet.
Dans "business", je vais créer un objet "searchFilter" qui va permettre de faire des filtres et des tris sur les données du DataSet.
Dans "facade", je vais créer un objet "searchDisplay" qui va me générer des éléments HTML listant les données du DataSet filtré, avec les évènements nécessaires pour relancer des filtres ou une recherche.
Dans "principal", je ne fais qu'instancier un objet "searchDiplay" et l'afficher.
 
Est-ce que ça vous semble viable ?
Est-ce que vous avez des conseils "basic" pour faire un site facile à développer et maintenir ? (oui, je sais, j'achèterai un bouquin sur le C# un jour, j'ai déjà récupéré la MSDN en Français, on va voir ce qu'on peut trouver dedans)

Reply

Marsh Posté le 06-01-2005 à 21:20:09   

Reply

Marsh Posté le 06-01-2005 à 21:36:06    

Moi je fais pareil, un projet par Layer. Et chaque Layer doit offrir un bon niveau d'abstraction, comme ça si un Layer devait changer, pas besoin de changer les autres.

Reply

Marsh Posté le 08-01-2005 à 19:03:37    

Pareil pour moi : Data Layer / Business Layer / Presentation Layer (avec parfois un Business Facade en plus, mais c'est rare)

Reply

Marsh Posté le 08-01-2005 à 23:24:51    

OK, merci. C'est pour le moment ce que j'ai donc choisi, et ça m'a l'air de ne pas poser de problème (sauf de compilation, je comprends pas : une fois sur deux il perd les références entre les projets et c'est très lourd ;))
 
PS: merci au modérateur qui s'est chargé du nettoyage :jap:
 
Sinon, pour entrer dans l'idée de FlorentG, qu'est-ce qu'on peut faire d'autre comme architecture ?

Reply

Marsh Posté le 08-01-2005 à 23:27:38    

ben tu pourrais rajouter encore un tier de plus, pour la deconne [:dawa]


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 09-01-2005 à 21:45:59    

Arjuna a écrit :

OK, merci. C'est pour le moment ce que j'ai donc choisi, et ça m'a l'air de ne pas poser de problème (sauf de compilation, je comprends pas : une fois sur deux il perd les références entre les projets et c'est très lourd ;))
 
PS: merci au modérateur qui s'est chargé du nettoyage :jap:
 
Sinon, pour entrer dans l'idée de FlorentG, qu'est-ce qu'on peut faire d'autre comme architecture ?


 
Je te recommande l'achat d'un bouquin sur les design pattern / achitectural pattern, tu y verras certainement plus clair qu'avec 3 explications données à la va vite sur un forum anti ms  [:guiotv2]


Message édité par ToxicAvenger le 09-01-2005 à 21:46:17
Reply

Marsh Posté le 10-01-2005 à 00:31:49    

par exemple le tres bon Patterns of Enterprise Application Architecture de Martin Fowler
(et bah ouais, les 3 layers, persistence/business/presentation, classique quoi [:spamafote])


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 10-01-2005 à 14:01:54    

Bon, tout à l'heure je vais aller voir la direction de ma boîte pour acheter des bouquins C#.
 
Je vais donc demander l'achat de celui-ci.
Mais d'un point de vue purement développement (orienté ASP.NET) vous me conseillez quoi ?
Si possible un bouquin "référence", c'est à dire que je ne suis pas plus emballé que ça par un bouquin qui propose le développement d'une appli pas à pas, mais plutôt un qui reprend chaque élément du SDK point par point, avec une explication et des exemples conrets de leur utilisation (pas seulement "ça fait ça et voici la syntaxe" ).
 
J'aimerais en fait, dans la démarche quelquechose qui ressemble à l'aide de SQL Server. Voici un article pour exemple :
 

Code :
  1. Référence de Transact-SQL
  2. BEGIN TRANSACTION
  3. Indique le début d'une transaction locale explicite. L'instruction BEGIN TRANSACTION incrémente de 1 la variable @@TRANCOUNT.
  4. Syntaxe
  5. BEGIN TRAN [ SACTION ] [ transaction_name | @tran_name_variable
  6.     [ WITH MARK [ 'description' ] ] ]
  7. Arguments
  8. transaction_name
  9. Nom attribué à la transaction. transaction_name doit respecter les règles applicables aux identificateurs, mais seuls les 32 premiers caractères de ce nom sont utilisés. Utilisez les noms de transaction seulement sur la paire la plus extérieure des instructions BEGIN...COMMIT ou BEGIN...ROLLBACK imbriquées.
  10. @tran_name_variable
  11. Nom d'une variable définie par l'utilisateur et contenant un nom de transaction valide. La variable doit être déclarée avec un type de données char, varchar, nchar ou nvarchar.
  12. WITH MARK ['description']
  13. Indique que la transaction est marquée dans le journal. description est une chaîne qui décrit la marque.
  14. Si WITH MARK est utilisé, un nom de transaction doit être spécifié. WITH MARK permet de restaurer un journal de transactions par rapport à une marque nommée.
  15. Notes
  16. BEGIN TRANSACTION représente le point auquel les données référencées par une connexion sont logiquement et physiquement cohérentes. Si des erreurs sont détectées, toutes les modifications apportées aux données après l'exécution de l'instruction BEGIN TRANSACTION peuvent être annulées afin que les données reviennent à cet état connu de cohérence. Une transaction se poursuit jusqu'à ce qu'elle se termine sans erreur et que l'instruction COMMIT TRANSACTION soit émise pour que les modifications soient intégrées de façon permanente à la base de données ou bien jusqu'à ce que des erreurs soient rencontrées, auquel cas les modifications sont effacées à l'aide de l'instruction ROLLBACK TRANSACTION.
  17. L'instruction BEGIN TRANSACTION démarre une transaction locale pour la connexion qui l'a émise. En fonction des paramètres de niveau d'isolation définis pour la transaction en cours, de nombreuses ressources acquises pour la prise en charge des instructions Transact-SQL émises par la connexion sont verrouillées par la transaction jusqu'à ce que celle-ci se termine soit par un COMMIT TRANSACTION soit par un ROLLBACK TRANSACTION. Les transactions suspendues pendant de longues périodes peuvent empêcher les autres utilisateurs d'accéder à ces ressources verrouillées.
  18. Lorsque BEGIN TRANSACTION démarre une transaction locale, celle-ci n'est pas enregistrée dans le journal des transactions avant que l'application n'effectue une action devant y être consignée, comme l'exécution d'une instruction INSERT, UPDATE ou DELETE. Une application peut effectuer des actions telles que l'acquisition de verrous afin de protéger le niveau d'isolation d'une transaction des instructions SELECT, mais rien n'est enregistré dans le journal avant que l'application n'effectue une action de modification.
  19. Il est inutile d'attribuer un nom à chaque transaction d'une séries de transactions imbriquées. En effet, seul le premier (le plus en dehors) nom de transaction est enregistré dans le système. Une annulation vers tout autre nom (autre que celui d'un point de sécurité valide) entraîne une erreur. Dans ce cas, aucune des instructions exécutées avant l'annulation n'est en fait annulée au moment où l'erreur se produit. Les instructions ne sont annulées que lorsque l'instruction extérieure l'est.
  20. BEGIN TRANSACTION démarre une transaction locale. La transaction locale est promue au rang de transaction distribuée si les actions suivantes sont effectuées avant qu'elle soit validée ou annulée :
  21. Exécution d'une instruction INSERT, DELETE ou UPDATE faisant référence à une table distante ou à un serveur lié. L'instruction INSERT, UDPATE ou DELETE échoue si le fournisseur OLE DB utilisé pour l'accès au serveur lié ne prend pas en charge l'interface ITransactionJoin.
  22. Un appel à une procédure stockée distante est effectué quand l'option REMOTE_PROC_TRANSACTIONS a la valeur ON.
  23. La copie locale de SQL Server devient le contrôleur de transaction et utilise MS DTC pour gérer la transaction distribuée.
  24. Transactions marquées
  25. L'option WITH MARK permet de placer le nom de la transaction dans le journal des transactions. Lors de la restauration d'une base de données dans un état antérieur, la transaction marquée peut être utilisée à la place d'une date et d'une heure. Pour plus d'informations, voir Restauration d'une base de données à un état antérieur, Récupération jusqu'à une transaction nommée et RESTORE.
  26. En outre, les marques du journal des transactions sont nécessaires pour récupérer un ensemble de bases de données connexes dans un état cohérent d'un point de vue logique. Une transaction distribuée permet de placer les marques dans les journaux de transactions des bases de données connexes. La récupération de l'ensemble de bases de données connexes jusqu'à ses marques aboutit à un ensemble de bases de données cohérent d'un point de vue transactionnel. Le placement de marques dans des bases de données connexes implique des procédures particulières. Pour plus d'informations, voir Sauvegarde et restauration de bases de données connexes.
  27. La marque n'est placée dans le journal des transactions que si la base de données est mise à jour par la transaction marquée. Les transactions qui ne modifient pas de données ne sont pas marquées.
  28. L'instruction BEGIN TRAN new_name WITH MARK peut être imbriquée dans une transaction existante non marquée. new_name devient alors le nom de marque de la transaction, malgré le nom éventuellement déjà affecté à la transaction. Dans l'exemple suivant, M2 est le nom de la marque.
  29. BEGIN TRAN T1
  30. UPDATE table1 ...
  31. BEGIN TRAN M2 WITH MARK
  32. UPDATE table2 ...
  33. SELECT * from table1
  34. COMMIT TRAN M2
  35. UPDATE table3 ...
  36. COMMIT TRAN T1
  37. Si vous essayez de marquer une transaction déjà marquée, vous obtenez un message d'avertissement (non d'erreur) :
  38. BEGIN TRAN T1 WITH MARK
  39. UPDATE table1 ...
  40. BEGIN TRAN M2 WITH MARK
  41. Server: Msg 3920, Level 16, State 1, Line 3
  42. WITH MARK option only applies to the first BEGIN TRAN WITH MARK.
  43. The option is ignored.
  44. Autorisations
  45. L'autorisation d'exécuter l'instruction BEGIN TRANSACTION est attribuée par défaut à tout utilisateur reconnu.
  46. Exemple
  47. A. Attribution d'un nom à une transactionCet exemple montre comment nommer une transaction. Dès la validation de la transaction nommée, les droits d'auteur versés pour tous les manuels d'informatique les mieux vendus sont majorés de 10 %.
  48. DECLARE @TranName VARCHAR(20)
  49. SELECT @TranName = 'MyTransaction'
  50. BEGIN TRANSACTION @TranName
  51. GO
  52. USE pubs
  53. GO
  54. UPDATE roysched
  55. SET royalty = royalty * 1.10
  56. WHERE title_id LIKE 'Pc%'
  57. GO
  58. COMMIT TRANSACTION MyTransaction
  59. GO
  60. B. Marquage d'une transactionCet exemple montre comment marquer une transaction. La transaction nommée « RoyaltyUpdate » est marquée.
  61. BEGIN TRANSACTION RoyaltyUpdate
  62.    WITH MARK 'Update royalty values'
  63. GO
  64. USE pubs
  65. GO
  66. UPDATE roysched
  67.    SET royalty = royalty * 1.10
  68.    WHERE title_id LIKE 'Pc%'
  69. GO
  70. COMMIT TRANSACTION RoyaltyUpdate
  71. GO
  72. Voir aussi
  73. BEGIN DISTRIBUTED TRANSACTION
  74. COMMIT TRANSACTION
  75. COMMIT WORK
  76. RESTORE
  77. Récupération jusqu'à une transaction nommée
  78. ROLLBACK TRANSACTION
  79. ROLLBACK WORK
  80. SAVE TRANSACTION
  81. Transactions
  82. ©1988-2000 Microsoft Corporation. Tous droits réservés.


 
=> On a le détail de la syntaxe, dont chaque élément est convenablement détaillé.
=> On a ensuite une explication technique et théorique de l'instruction avec des Tips d'utilisation (limitation, etc.)
=> Des explication sur des fonctionnalités dérivées (ici, les "transactions marquées" )
=> Des exemples de l'instruction, permettant de se rendre compte du fonctionnement, et prévoir les erreurs possibles.
 
Personnellement, je trouve très clair ce genre d'explications, et j'y suis très habitué. Si on n'a pas toujours une vision globale de l'implémentation des éléments, au moins on les comprends correctement de façon unitaire, ce qui me semble le plus intéressant. Je n'aime pas les exemples de 3 pages auxquels on ne comprend pas un traître mot.

Reply

Marsh Posté le 10-01-2005 à 14:04:16    

y'a bien un genre de javadoc pour c# non ?


---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?
Reply

Marsh Posté le 10-01-2005 à 14:10:21    

Chais pas, moi ça n'a jamais marché.
 
Et de toute façon, en plus de l'aide MSDN (que je ne désepère pas de réussir à installer un jour :D) je préfèrerais un bouquin, on peut le potasser sans être derrière son écran.

Reply

Marsh Posté le 10-01-2005 à 14:10:21   

Reply

Marsh Posté le 10-01-2005 à 14:13:18    

conseil pour le bouquin : n'achete pas celui de Leblanc, il a juste traduit msdn :/


Message édité par KangOl le 10-01-2005 à 14:13:44

---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le 10-01-2005 à 14:15:04    

euh, d'accord, je le note :D mais sinon, j'achète quoi du coup :D

Reply

Marsh Posté le 10-01-2005 à 14:17:55    

Dans le temps, leblanc a fait de bon bouquins sur les produits borland et puis d'un coup il est devenu pro-microsoft !! mais son bouquin sur c# est a proscrire, il y a mieux... mais je saurait pas te dire quoi :D


---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le 10-01-2005 à 14:34:46    

rhô :o


Message édité par Arjuna le 10-01-2005 à 14:34:59
Reply

Marsh Posté le 30-01-2005 à 01:19:01    

en bouquin moi j'aime bien tout les bouquins des collection msPress, j'ai tout ceux sur asp.net en francais :D et celui que je prefere et de loin et celui de Richard Clark : formation à asp.net il est basique mais m'a permis d'apprendre ... sinon asp.net pas à pas et pas mal par contre il doit etre cher mais je m'en fous je l'ai pas payé ;) (fallait aller au student club summit :D)  
 
sinon pour de l'aide détaille du SDK, le MSDN c'est vraiment le pied :D si tu as VS.net il est installé d'office :D si tu l'as pas : vas sur http://hoshimi.codes-sources.fr/ dans une news j'explique comment l'avoir gratuitement et légalement ainsi qu'office.  
 
Sinon un bon site pour apprendre : www.aspfr.com je réponds à quasi toutes les questions sur le forum, et généralement je réponds où il faut :o

Reply

Marsh Posté le 30-01-2005 à 01:52:21    

Bon, j'ai pas tout lu, mais je tiens quand même à faire une remarque :
 
L'abstraction, les couches, tout ça c'est super pour la réutilisation et la maintenabilité, mais ça a un gros défaut.
 
Les développeurs ne réfléchissent plus à ce qu'il font et dans beaucoup de cas on se rend compte qu'ont fait de milliers de requêtes unitaires pour afficher 3 enregistrements !
 
Et qui c'est qu'on appelle après pour pondre la requête qui va rendre le truc utilisable ? C'est bibi, parce que plus personne ne sait écrire une requête un peu compliquée et surtout bien optimisée.
 
L'optimisation, ça ne se fait pas après, c'est au moment du design de la base et du Projet "database" qu'il faut y penser ! Sinon, on fini par être obligé de faire des trucs bien crado pour tenir la charge et les temps de réponses.
 
Mettre toute l'intelligence dans le Projet "business" est super beau d'un point de vue esthétique, mais à mon sens, choisir Oracle ou Postgres (ou un autre SGBD un peu évolué) et ne pas lui demander ce qu'il sait TRES bien faire est une vate connerie.
 
A+


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 30-01-2005 à 12:40:30    

Euh... Ben nous, toutes les requêtes on les mets dans la base hein !
Quand je parle de "l'inteligence" dans l'objet business, ce que je veux dire, c'est que c'est lui qui va s'occuper de savoir quels procédures stockées lancer en fonction des données qu'on est en train de traîter par exemple. Mais les traîtements sur les données en tant que tels sont exclusivement dans la base de données !

Reply

Marsh Posté le 30-01-2005 à 13:31:15    

Ok, tout à fait d'accord avec ça.
 
Ca va mieux en le disant non ?


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 30-01-2005 à 14:39:53    

ben pour moi ça va tellement de soit que je pensais pas avoir besoin de l'indiquer :p

Reply

Marsh Posté le 30-01-2005 à 16:07:22    

En fait, c'est ça qui ma fait un peur peur ;)
 

Citation :

Dans "business", je vais créer un objet "searchFilter" qui va permettre de faire des filtres et des tris sur les données du DataSet.


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 30-01-2005 à 16:10:47    

Ben ça, c'est dans le cas d'un écran de recherche multi-critère. Au lieu d'écrire 25 proc stock pour traîter tous les cas, ou alors générer à la voler la requête dans la proc stock, je fais une unique recherche, qui prends par exemple le critère le plus restrictif, puis je fais les filtres subsidiaires dans l'objet.

Reply

Marsh Posté le 30-01-2005 à 16:36:31    

C'est justement là que ça fini toujours par coincer.
 
Tout ça pour afficher les enregs par page de 5 avec une requête qui t'en ramène 10 000 ou 100 000... ( ben oui, des fois ça va très vite :/ )
 
Il est souvent assez facile de réduire le nombre de requêtes paramétrables pour ne pas en écrire 25 ou 50 et surtout ne pas générer dynamiquement la requête, du moins dans une proc-stockée.
 
M'enfin je te dis ça, t'as l'air d'avoir compris ma "préocupation", c'est le principal ;)


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed