根据封装对象的类型初始化派生类

发布于 2024-11-26 12:07:02 字数 1309 浏览 4 评论 0原文

我有一个数据访问对象库,并负责设计逻辑层。在这一层中,我可以访问核心数据模型,我需要使用它来创建可以传递到 UI 进行渲染的 Profile 对象。

数据模型中需要等效 Profile 对象的每个对象都派生自类型 Page。因此,理想情况下,我需要编写一种接受 Page 作为参数并返回 Profile 的方法。然而,事情并不那么简单,因为 Profile 对象被分成用户可以启用的应用程序组。

我尝试了各种不同的方法(并继续删除全部内容并重新开始!),但这是我目前正在尝试的解决方案:

public interface IApp
{
    //should be static, but interfaces cannot define static properties
    //so this instance property will return a private static field
    Dictionary<Type, IProfileCreator> Profiles { get; }

    //other things the App contains that isn't relevant to the profiles
}

public interface IProfile
{
    Page page { get; set; }
}

public interface IProfileCreator
{
    IProfile Create(Page page);
}

public class ProfileCreator<TProfile> where TProfile : IProfile, new()
{
    IProfile IProfileCreator.Create(Page page)
    {
        return Create(page);
    }

    public TProfile Create(Page page)
    {
        //constructor will have to be blank because of the new() constraint
        TProfile profile = new TProfile();
        profile.Page = page;
        return profile;
    }
}

我必须为以下对象创建 24 个相当大的 Profile 类 :不同的页面,所以我只想确保在开始编码之前我正在以最好的方式做这件事。正如您所看到的,这个设计有一些缺陷,但是有更好的方法吗?有没有人尝试过类似的事情(这种情况不会那么罕见,不是吗)?

I've have a library of data access objects and am tasked with designing the logic layer. In this layer, I have access to the core data model, which I need to use to create Profile objects that can be passed to the UI for rendering.

Every object in the data model that needs an equivalent Profile object derives from the type Page. So ideally I need to write one method that accepts a Page as a parameter and returns a Profile. It's not quite as simple as this, however, because the Profile objects are split into groups of Apps, which the user can enable.

I've tried various different approaches (and keep on deleting the whole lot and starting again!), but here's the solution I'm trying at the moment:

public interface IApp
{
    //should be static, but interfaces cannot define static properties
    //so this instance property will return a private static field
    Dictionary<Type, IProfileCreator> Profiles { get; }

    //other things the App contains that isn't relevant to the profiles
}

public interface IProfile
{
    Page page { get; set; }
}

public interface IProfileCreator
{
    IProfile Create(Page page);
}

public class ProfileCreator<TProfile> where TProfile : IProfile, new()
{
    IProfile IProfileCreator.Create(Page page)
    {
        return Create(page);
    }

    public TProfile Create(Page page)
    {
        //constructor will have to be blank because of the new() constraint
        TProfile profile = new TProfile();
        profile.Page = page;
        return profile;
    }
}

I have to create 24 fairly big Profile classes for different pages, so I just want to make sure I'm doing it the best way I can before I start coding away. As you can see this design has a few flaws, but is there a better way of doing this? Has anyone tried a similar thing before (this situation can't be that rare, can it)?

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

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

发布评论

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

评论(1

酷炫老祖宗 2024-12-03 12:07:02

看看这个 Factoy PAttern ():

  abstract class ProfileFactory 
    { 
        public abstract IProfile GetProfile(Page p); //Factory Method Declaration 
    }

class concreteFactoryforProfile1 : ProfileFactory 
    {
    public override IProfile GetProfile(Page p) //Factory Method Implementation 
            { 
                //data access stuff...
                return new Profile() { Page = p }; 
            } 
    }

class concreteFactoryforProfile2 : ProfileFactory 
    {
    public override IProfile GetProfile(Page p) //Factory Method Implementation 
            { 
                //other data access stuff...
                return new Profile() { Page = p };
            } 
    }


interface IProfile 
    { 
        Page Page { get; set; } 
        //other properties can come here
    }

class Profile : IProfile
    { 
        public  Page Page { get; set; }
        //other properties can come here
    }


public class Test
{
    void Main()
    {

        ProfileFactory[] objFactories = new ProfileFactory[2];
        objFactories[0] = new concreteFactoryforProfile1();
        objFactories[1] = new concreteFactoryforProfile2();
        foreach (ProfileFactory objFactory in objFactories)
        {
            IProfile objProfile = objFactory.GetProfile(this.Page);
            Page p = objProfile.Page;
        }
    }
}

然后两个应用程序可能具有相同类型的对象,您的对象创建的实现将只完成一次。

如果您需要更多详细信息,请询问。

Have a look at this Factoy PAttern (source):

  abstract class ProfileFactory 
    { 
        public abstract IProfile GetProfile(Page p); //Factory Method Declaration 
    }

class concreteFactoryforProfile1 : ProfileFactory 
    {
    public override IProfile GetProfile(Page p) //Factory Method Implementation 
            { 
                //data access stuff...
                return new Profile() { Page = p }; 
            } 
    }

class concreteFactoryforProfile2 : ProfileFactory 
    {
    public override IProfile GetProfile(Page p) //Factory Method Implementation 
            { 
                //other data access stuff...
                return new Profile() { Page = p };
            } 
    }


interface IProfile 
    { 
        Page Page { get; set; } 
        //other properties can come here
    }

class Profile : IProfile
    { 
        public  Page Page { get; set; }
        //other properties can come here
    }


public class Test
{
    void Main()
    {

        ProfileFactory[] objFactories = new ProfileFactory[2];
        objFactories[0] = new concreteFactoryforProfile1();
        objFactories[1] = new concreteFactoryforProfile2();
        foreach (ProfileFactory objFactory in objFactories)
        {
            IProfile objProfile = objFactory.GetProfile(this.Page);
            Page p = objProfile.Page;
        }
    }
}

Then two App might have the same type of Object, your implementation of the creation of the object will be done only once.

If you need further details, please ask.

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