L'équipe de sortie est en train de créer une application N-Tier qui traitera de nombreuses méthodes de base de données et de réseau.Conception de gestion d'erreur N-Layer/N-Tier
Fondamentalement, nous avons conçu les couches suivantes (du bas vers le haut):
couche de données: Peut-être Oracle ou SQL (essentiellement une entité EF et généré automatiquement contexte utilisant la base de données d'abord) couche persistante: gérer les données étage. Nous avons un niveau persistant pour Oracle et un autre pour SQL avec quelques petits changements entre eux (nous voudrions réfractaire que dans le futur avoir un seul code - des idées acceptées). Couche métier: gère la logique d'application spécifique. Au-dessus de cela, nous pouvons avoir une couche de présentation (ASP.NET App), une API qui appelle directement les fonctions métier, un agent réseau qui permettra les requêtes métier du réseau, etc.
Nous avons des doutes concernant le mécanisme de gestion des erreurs. Nous avons décidé que toutes les exceptions sont traitées sur les couches de gestion, c'est donc le seul endroit où j'ai des instructions try/catch. Notre point est que nous ne voulons pas que les utilisateurs de l'application se débarrassent des exceptions, mais ils doivent connaître l'état des opérations. Nous avons créé une classe ReturnStatus qui ressemble à:
public class ReturnStatus
{
public enum ReturnStatusTypes : int { Success, Failure, Unknown }
public ReturnStatusTypes Status;
public int MessageCode;
public string Message;
/// <summary>
/// Class constructor
/// </summary>
public ReturnStatus()
{
Status = ReturnStatusTypes.Unknown;
MessageCode = 0;
Message = "";
}
/// <summary>
/// Class constructor
/// </summary>
/// <param name="status">Status</param>
/// <param name="message">Message</param>
public ReturnStatus(ReturnStatusTypes status, int msgCode)
{
Status = status;
MessageCode = msgCode;
Message = ErrorMessages.ResourceManager.GetString("ErrorCode" + msgCode);
}
}
La propriété du message est localisable en fonction de la culture App mis devant.
Nous souhaitons que chaque appel à une méthode de couche métier ait un état de retour. Cela peut être enregistré dans la barre d'état ASP.NET, renvoyé à l'API ou envoyé sur le réseau aux autres applications. Le problème est que la plupart de nos classes métiers renvoient des données, nous devons donc trouver un moyen de renvoyer le statut et les données ensemble aux acteurs consommateurs.
Notre personnel envisage: a) Utiliser des tuples à chaque appel. Cela ne semble pas être la façon recommandée. b) Jeter une attente: pas conforme à notre architecture. c) Utilisation de ReturnStatus à chaque appel: Considérée comme une option, même à l'ancienne. d) Garder un dernier objet d'erreur quelque part, afin que l'appel puisse renvoyer directement des données et que l'utilisateur puisse appeler lastactionstatus pour obtenir cette erreur. Notre point est: nous ne savons pas où stocker ces dernières données d'erreur. Sur un cours de singleton?
La solution doit être uniforme entre toutes les méthodes de gestion.
Que recommanderiez-vous pour la meilleure méthode et comment l'implémenter.
Nous savons comment gérer les exceptions. Ce n'est pas le problème ou la question. Notre question concerne la méthode que nous devrions utiliser sur les couches utilisateur, car nous ne voulons pas propager le gestionnaire d'exceptions. – Mendes
Je me demandais si ce travail gona Vous devez vérifier les stauts chaque fois que c'est un très vieux style de programmation et que le programmeur le plus C et C++ l'utilise encore dans les systèmes embarqués. Je vous recommande fortement de redésigner la gestion des exceptions dans votre architecture, vous ne pourrez jamais obtenir ce système stable ou peut-être manquer quelque chose parce que je n'ai pas le code source et tout le processus de gestion des erreurs dans votre logiciel. –
D'accord. Les codes de retour se sentent mal. Je ne vois pas de problème à laisser des exceptions apparaître à travers les couches. Vous avez rencontré le problème avec les codes de retour - parce que vous renvoyez un code, vous ne pouvez pas renvoyer de données, donc vos méthodes ont besoin de vous «out» ou «ref». Laisser les exceptions se produire et les gérer comme il convient dans le dernier palier. –