Logique métier - organisation et questions diverses

Bonjour,

j'ai développé une appli depuis quelques temps où j'ai organisé la code de la manière suivante.

Contrôleur : validation, renvoi de vues
Service : déléagation de la logique métier à laquelle j'ai mis des instances de modèles en paramètres de constructeur
Modèle : couche d'accès aux données uniquement, et renvoi de la requête SQL.

Maintenant, à revoir l'intégralité du projet; je me rend compte des choix pour le moins discutables que j'ai fait :
- Pourquoi ne pas permettre au besoin d'appeler la BDD dans le contrôleur s'il n'y a aucune logique métier derrière ? Ex : Order.all() pour récupérer toutes les commandes d'un client. Inutile d'abstraire ça dans un service s'il s'agit juste de faire ça
- Pourquoi appeler un Service 'Service' pour stocker sa logique métier ? Cela aurait du sens si une application expose à d'autres appli, mais pas pour stocker de la logique métier. L'appel d'un service web peut être considéré comme un service, tout comme du code qui se connecte à des API externe, type Google etc... car ce sont des services en tant que tel.

Seulement voilà, la validation de modèle est énormément liée au contexte dans lequel elle est faite et donc il n'esiste pas forcément une seule règle pour un champ en base. Comment régler ses problèmes proprement quand le code grandit ?

J'ai déjà une réponse partielle :
- organiser son code de manière fonctionnelle, c'est les fonctionnalités qui doivent déterminer la structure du code et non l'IHM. Par ex : l'enregistrement de l'utilisateur (inscription), login, affichage de commandes etc,
- qu'une vue ne réponde qu'a un seul cas d'utilisation. Par exemple, pour le cas de commandes, avoir des vues différentes pour : un utilisateur qui n'a pas du tout passé de commande, et une autre quand il en a plusieurs, une vue différente pour une interface d’administration utilisée en interne
- le nommage de méthode, j'ai eu du code avec des méthodes de ce type : updateMachin(), updateTruc(), comment les éviter ? Utiliser une interface avec juste une méthode update() ou du CRUD type new, update, delete ? N'est-ce pas inutile de se forcer à utiliser toutes ces méthodes pour des objets où l'on ne veut que faire des MAJ par ex ?

Autres questions en vrac :
- que signifie le paramètre générique <T> que l'on peut voir dans les listes par ex ?
- quand j'utilise DbContext, qu'est-ce que je manipule exactement ?

Par ex :

Code:

---

1 2 3 4

using (var context = new BloggingContext()) { var blogs = context.Blogs.ToList(); }

---

la variable context est quoi exactement ? Une connexion à la BDD ? Liée à quelle table ?

Je comprends ce que cela fait mais j'aime comprendre les données que je manipule.

De bonnes pratiques à partager ?

je ne répondrais pas sur la structure (pas tout suivi et chacun fait un peu ce qu'il veut selon ce qu'il a à faire)


concernant <T> les generics servent à faire abstraction du type tout en faisant marcher la classe
si tu utilises le type collection, tu peux y mettre tout et n'importe quoi dedans, mais après tu es obligé de caster à chaque fois que tu récupères quelque chose dedans
les generics sont donc plus pratique, T sera un type variable selon l'utilisation, comme si on avait écrit une classe list pour chaque type qui peut exister

tu peux toi même faire des classes génériques, par exemple

Code:

---

1 2 3 4 5 6

public class WebServiceResult<T> { public bool Successfull {get;set;} public string ErrorMessage {get;set;} public T DataAssociated {get;set;} }

---

ici un exemple de classe de retour de webservice qui permet de savoir si l'appel a réussi, avoir un message en cas d'erreur, et avoir un résultat en plus, qui est typé sur ce qu'on veut
on instancie en spécifiant que vaudra T pour cette instance, et ca reste figé pour cette instance

Code:

---

1 2	var r = new WebServiceResult<int?>(); r.DataAssociated = 5;

---

Code:

---

1 2	public WebServiceResult<PostalAddress> GetAddress(int idPerson); public WebServiceResult<string> GetName(int idPerson);

---

l'appelant en faisant .DataAssociated aura directement une adresse, un string ou autre selon le cas, sans avoir à caster, et sans faire une classe pour chaque type




concernant ta variable context je pense que ca vient d'EF, auquel cas c'est un contexte de base de données basé sur le modèle que tu as dans visual studio (liste de tables etc.) et à l'exécution ca contient aussi la connexion, l'états des objets …
après si tu veux savoir ce que tu fais tu peux te passer d'EF et utiliser ADO.NET