将 System.Web 引用添加到 n 层架构中的业务逻辑层

发布于 2024-10-13 20:38:48 字数 1610 浏览 6 评论 0原文

我正在使用 TableProfileProvider 在 n 层架构中使用 ASP.NET 配置文件系统。
UI 层是一个 Web 应用程序,因此我必须公开 profilecommon 类才能使用配置文件。
这是我的架构的简化架构:
UI: ASP.NET Web 应用程序。
BusinessEntities:纯 POCO 类。坚持不懈。
BLL:业务逻辑层。
DAL:数据访问层。

Profilecommon 的定义是:

 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);
        }
    }
 }  

在一个简单的设计架构中,所有内容都在 Web 应用程序项目中定义,我将按如下方式访问 profilecommon:
ProfileCommon StrongleyTypedProfile = (ProfileCommon)this.Context.Profile;

我希望能够从业务逻辑层访问 Profile Common,因此我将 ProfileCommon 定义移至 BusinessEntities 库(必须在 BusinessEntities 库中添加对 System.Web 程序集的引用)并定义新的 ProfileBLL 类:

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;
    }
}  

现在我可以像这样从 UI 访问通用配置文件:

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

现在,在业务层/业务实体库中引用 System.Web 是否违反了 n 层架构规则?如果是这样,为了实现这一目标,您有何建议?

I'm using TableProfileProvider to use ASP.NET profile system in an n-layer architecture.
The UI layer is a web application so I have to expose the profilecommon class to be able to use profiles.
Here's a simplified schema of my architecture:
UI: ASP.NET Web Application.
BusinessEntities: Pure POCO Classes. Persistence Igronace.
BLL: Business logic layer.
DAL: Data Access Layer.

The Profilecommon definition is:

 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);
        }
    }
 }  

In a simple design architecture where everything is defined in the web application project, I'd access the profilecommon as follows:
ProfileCommon strongleyTypedProfile = (ProfileCommon)this.Context.Profile;

I'd like to be able to access the Profile Common from my Business Logic Layer, So I moved the ProfileCommon definition to my BusinessEntities Library (Had to add reference to System.Web assembly in BusinessEntities library) and defined the new ProfileBLL Class:

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;
    }
}  

Now I can access profile common from UI like this:

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

Now, is referencing System.Web in Business Layer/BusinessEntities Library violates the n-layer architecture disciplines? If so, What would you suggest in order to achieve this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

感受沵的脚步 2024-10-20 20:38:48

您可以通过实现接口来打破对 ProfileBase 的依赖。可以说,

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;
    }
} 

现在您的业务逻辑中不再依赖 System.Web.dll,但仍然可以自由地使用 ProfileBase 在 Web 应用程序中实现 IProfile 接口

You can break the dependency on ProfileBase by implementing a interface instead. Lets say

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;
    }
} 

Now you don't have any dependency on System.Web.dll in your Business Logic but still have the freedom to implement the IProfile interface in your webapplication using the ProfileBase

微暖i 2024-10-20 20:38:48

您不应该从业务层访问 System.Web。这将您与网络应用程序的工作联系起来。如果您想在不同类型的应用程序中重用业务层怎么办?

你应该问自己,你想通过这个实现什么目标。然后,将该需求抽象为业务层可以访问的通用合理内容。这假设业务层应该完全了解用户。

You should not be accessing System.Web from the business layer. That ties you to working with a web application. What if you wanted to reuse the business layer in a different kind of application?

You should ask yourself what you're trying to accomplish by this. Then, abstract that requirement into something generic reasonable for the business layer to access. This assumes that the business layer should know about users at all.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文