Ce que ce Framework apporte d�pend pas mal de ceux qui l'utilisent...
En ce qui concerne les couches :
Pour les d�butants, il offre un projet pr� structur� en couches tr�s claires.
Il y en a beaucoup, c'est vrai, mais c'est tr�s pratique (surtout quand c'est d�j� fait).
Pour les d�veloppeurs plus confirm�s, ma structuration en couche n'est pas super moderne mais j'ai voulu qu'elle soit tr�s claire et �viter les concepts compliqu�s.
Toutes les r�f�rences entre les couches sont faites et il ne faut pas y toucher.
En ce qui concerne la g�n�ration :
Le framework contient des .tt r�partis � des endroits appropri�s.
On g�n�re l'EDMX en choisissant la strat�gie de g�n�ration de code : aucune
On reconstruit l'ensemble des tt
- tables d'options (que j'ai l'habitude d'appeler lookups) sont automatiquement converties en enum. Ce qui permet de faire des switch � l'aide d'un petit outil du framework EnumTypeTo<T> qui permet de passer de l'int de l'Id � sa valeur ennum�r�e, c'est SUPER PRATIQUE.
et �a fonctionne aussi dans l'autre sens EnumTools.EnumTypeTo<int>(enTypesBranches.applicationpool)
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8 switch (EnumTools.EnumTypeTo<enTypesBranches>(model.typeNodeId)) { #region applicationpool case enTypesBranches.applicationpool: bla bla bla break; }
- domain (je pense que j'aurais du appeler �a entities mais finalement c'est assez clair) : C'est l� que sont g�n�r�es les classes entit�s � la place de celles qui sont g�n�r�es par l'edmx. Ces classes ont les m�mes limitations que les entities de l'EF.
- MetaData : Ce sont des objets qui ont strictement la m�me signature que les entit�s mais sans la navigation. Il sont d�cor�s des data annotations localis�es (toutes, y compris celles qui ne pouvaient pas l'�tre dans la version d'origine), les ressources associ�es sont li�es par un Tag pr�fix� Ety_...
Depuis hier, un nouveau tt va g�n�rer l'ensemble des ressources dont les chaines seront pr�fix�es par deux _ (ce tt conserver les chaines ajout�es � la main d'une g�n�ration � l'autre, il g�n�re autant de lanques qu'on veut, il suffit donc d'envoyer les XML � un traducteur par langue et de r�int�gr� �a.
- Dto : M�me principe que les MetaData mais les classes et les membres sont d�vor�s avec les [DataContract] et [DataMember]
- DataRepository : une seule classe pour tous les datarepositories (on aurait pu faire une classe par DR comme certain le font, c'�tait plus simple pour moi de faire comme �a).
TRES IMPORTANT : L'ensemble des E/S en base supporte les Transactions.
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41 [HttpPost] public JsonResult Arbre_CreationBranche(string authority) { JavaScriptSerializer serializer = new JavaScriptSerializer(); Arbre_ActionBranche_JSon model = serializer.Deserialize<Arbre_ActionBranche_JSon>(Request.Form[0]); using (TransactionScope TS = new TransactionScope()) { try { using (InnovaCMSRepositories _context = new InnovaCMSRepositories()) { InnovaTreeTools TreeTools = new InnovaTreeTools(_context); Hierarchy nouvelleBranche = TreeTools.CreationBranche(model.title, model.parentId, model.position, model.typeNodeId); switch (EnumTools.EnumTypeTo<enTypesBranches>(model.typeNodeId)) { case enTypesBranches.storagefolder: using (InnovaCMSServices.IOManagerClient _serviceContext = new InnovaCMSServices.IOManagerClient()) { //ToDo:Ici //_serviceContext.Folder_Create() } break; case enTypesBranches.storagefile: break; default: throw new NotSupportedException(); } } TS.Complete(); } catch (Exception ex) { TS.Dispose(); throw ex; } } throw new NotImplementedException(); }
La combinaison de ces trois cat�gories d'objets (mapp�s les un sur les autres avec EmmitMapper) permet d'utiliser une couche business commune aux portails et aux web services (en gros on d�veloppe le portail en rangeant bien son code dans la couche business et il devient naturel de doter les portails d'une API en plus des services business).
Sur mon projet en cours, il n'y a plus que le syst�me des ressources g�n�r�es mais je n'ai pas encore eu le temps de le r�-int�gr� au Framework.
En ce qui concerne la communication entre le mod�le et la vue
la vue et la vue layout, il y a un les contr�leurs h�ritent d'un _Controllers_Base<T> where T:_Models_Base
En d'autres termes, toutes les membres n�cessaires � la vue layout sont d�clar�s dans _Models_Base, �a permet de convertir le model en _models_base dans la vue layout et donc de b�n�ficier de membres fortement typ�s et permet de ne pas avoir � utiliser le ViewBag.
Petit d�savantage, manipulation d'un seul mod�le par controlleur (pour ceux qui utilisent la vue layout et donc, pas pour les vues partielles).
En ce qui concerne la communication entre les controlleurs et les fichiers CSS et Javascript.
Chaque Vue [View] dispose
- Javascript (JQuery) ino[View].js
- Javascript (JQuery) ino[View]DocReady.js
- Javascript (JQuery) inoDynamic[View].js (facultatif) g�n�r�e par une vue afin de passer des valeurs depuis le serveur aux scripts charg�s par l'interm�diaire de variables (script construit c�t� serveur)
C'est ultra pratique pour configurer dynamiquement certains composants JQuery UI (jstree, jqgrid que j'utilise en JQuery UI Pur et non dans sa version mvc).- css ino[View].css
- css inoDynamic[View].css (facultatif) m�me principe que le fichier javascript dynamique.
En ce qui concerne le javascript, plus de javascript au profit du JQuery.
Pour ma part, j'utilise power amc combin� avec 3 scripts SQL en plus de celui qui est g�n�r� par power amc
Destruction de la base
Re cr�ation de la base
Injection de la structure g�n�r�e par Power AMC
Re injection des donn�es (bien entendu, ce script doit parfois �tre modifi� � la main).
La connections � la base est ouverte une seule fois par m�thode publique (get/post) du contr�leur.
Je dois encore am�liorer le concept en particulier pour la couche de s�curit� qui ne s'appuie pas sur cette connexion mais qui ouvre et ferme une connexion ind�pendantes.
Lorsque le starter kit sera termin�, il y aura des controleurs et des vues pour concus pour faciliter la compr�hension de tout �a.
De mon point de vue (mais je ne suis pas objectif)... Ca me parait �tre le meilleur compromis souplesse / stabilit�.
Une fois qu'on a compris la fa�on de l'utiliser, �a fait gagner beaucoup de temps et en particulier en mode agile o� on restructure la base fr�quemment.
Tous les web services sont structur�s de la m�me facon :
MethodeResult Methode (MethodeQuery query) {
implementation.... (utilisation de classes d'impl�mentation qui utilisent les classes de la couche business).
}
C'est super pratique...
MethodeResult h�rite de IResult
MethodeQuery h�rite de IQuery
ces deux interfaces permettent de forcer le d�veloppeur � impl�menter des membres qui permettent de monitorer le tout.
La couche common permet de partager les objets entre plusieurs portails et plusieurs web services.
Pour conclure (pour ce soir) je dirais que c'est un projet hyper factoris�, quasement pas de redondance de code.
Impl�mentation de log4net
il y a tout les outils n�cessaires pour r�ussir son projet MVC aussi important soit-il (encore une fois, c'est selon moi et je ne suis pas objectif).
++
Laurent
Partager