Question

J'utilise TableProfileProvider à utiliser le système de profil ASP.NET dans une architecture n-couche.
La couche d'interface utilisateur est une application web, donc je dois exposer la classe ProfileCommon pour être en mesure d'utiliser des profils.
Voici un schéma simplifié de mon architecture:
interface utilisateur. Application Web ASP.NET
BusinessEntities: Classes de POCO pur. La persistance Igronace.
BLL: couche logique métier
. DAL: Accès aux données couche.

La définition ProfileCommon est:

 public class ProfileCommon : ProfileBase
 {
    public virtual ProfileCommon GetProfile(string username)
    {
        return (ProfileCommon)ProfileBase.Create(username);
    }

    public virtual string FirstName
    {
        get
        {
            return (string)base.GetPropertyValue("FirstName");
        }
        set
        {
            base.SetPropertyValue("FirstName", value);
        }
    }
 }  

Dans une architecture simple de conception où tout est défini dans le projet d'application Web, je voudrais accéder au ProfileCommon comme suit:
ProfileCommon strongleyTypedProfile = (ProfileCommon) this.Context.Profile;

Je voudrais pouvoir accéder au profil commun de ma couche logique métier, donc je me suis déplacé la définition ProfileCommon à mon BusinessEntities Library (Nous avons dû ajouter une référence à System.Web assemblage dans la bibliothèque de BusinessEntities) et a défini le nouveau ProfileBLL classe:

public class ProfileInfo
{
    public ProfileInfo(ProfileCommon profile)
    {
        this.Profile = profile;
    }

    public ProfileCommon Profile { get; set; }

    public string GetFullName()
    {
        return this.Profile.FirstName + " " + this.Profile.LastName;
    }
}  

Maintenant je peux accéder à profil commun de l'interface utilisateur comme ceci:

var profileInfo = new BLL.ProfileInfo((ProfileCommon)this.Context.Profile);
txtFullName.text = profileInfo.GetFullName();

, fait référence System.Web dans la couche Business / BusinessEntities Library viole les disciplines de l'architecture n-couche? Si oui, Que proposeriez-vous pour y parvenir?

Était-ce utile?

La solution

Vous pouvez briser la dépendance à l'égard ProfileBase en mettant en œuvre une interface à la place. Disons que

public interface IProfile
{
    string FirstName { get; set; }
    string LastName { get; set; }

    IProfile GetProfile(string username);
}

public class ProfileCommon : ProfileBase, IProfile
 {
    public virtual IProfile GetProfile(string username)
    {
        return (ProfileCommon)ProfileBase.Create(username);
    }

    public virtual string FirstName
    {
        get
        {
            return (string)base.GetPropertyValue("FirstName");
        }
        set
        {
            base.SetPropertyValue("FirstName", value);
        }
    }
 }

public class ProfileInfo
{
    public ProfileInfo(IProfile profile)
    {
        this.Profile = profile;
    }

    public IProfile Profile { get; set; }

    public string GetFullName()
    {
        return this.Profile.FirstName + " " + this.Profile.LastName;
    }
} 

Maintenant, vous ne pas dépendance à l'égard System.Web.dll dans votre logique d'affaires, mais toujours la liberté de mettre en œuvre l'interface IProfile dans votre application web en utilisant le ProfileBase

Autres conseils

Vous ne devriez pas être en train d'accéder System.Web de la couche d'affaires. Ce lien vous à travailler avec une application web. Que faire si vous voulez réutiliser la couche métier dans une sorte d'application différente?

Vous devriez vous demander ce que vous essayez d'accomplir par cela. Ensuite, cette exigence abstraite en quelque chose de générique raisonnable pour la couche d'affaires d'accès. Cela suppose que la couche d'affaires devrait connaître les utilisateurs du tout.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top