在C#中调度类型vs多态。业务实体和非业务逻辑

时间:2014-12-18 17:49:04

标签: c# design-patterns single-responsibility-principle open-closed-principle

我想根据对象的类型对对象执行一些操作(db persistence,json serialization等)。多态性是通常的方法,但我不想在我的模型中添加很多非业务逻辑。

这是一个简单的类型层次结构(这些不是我的原始类型,而是显示问题的简化):

public abstract class Book
{
    public int Id { get; set; }
    public string Title { get; set; }
}

public class PrintBook : Book
{
    public decimal Weight { get; set; }
    public CoverType CoverType { get; set; }
}

public class Ebook : Book
{
    public EbookType Type { get; set; }
    public bool AutoUpgrade { get; set;}
}

这些书在客户端创建为JS对象,然后,它们作为JSON(我无法更改其结构)发送到服务器,被解析为书籍列表:

public List<Book> ParseJson(string json)
{
    /* JSON sample (in JS we have duck typing - the type is determined by its members)
    "books": [
        { "id": 1, "title": "Sample print book", "weight": 50, "coverType": "soft" },
        { "id": 2, "title": "Sample ebook", "type": "pdf", "autoUpgrade": true }
    ]
    */
}

然后,我想将此列表保存到数据库中:

public void SaveBooksToDatabase(List<Book> books)
{
    foreach (var book in books)
    {
        if (book is Ebook)
        {
            Save((Ebook)book);
        }
        else if (book is PrintBook) 
        {
            Save((PrintBook)book);
        }
    }
}

public void Save(Ebook ebook) { /* */ }

public void Save(PrintBook printBook) { /* */ }

我对SaveBooksToDatabase方法中的类型调度不满意:它违反了Open-Closed原则,并且在我们添加新类型时不是很安全。

但是我不想在书籍层次结构中添加一个抽象的Save()方法,因为除了保存之外还有更多类型相关的操作(例如json序列化),这会违反单一责任原则。我知道访客模式可能被认为是一种替代解决方案,但IMO会引入更多杂乱的样板代码。

处理此类案件的最佳方式是什么?

1 个答案:

答案 0 :(得分:2)

我会保持客户端发送的对象与知道如何自行保存的业务对象之间的分离。

我有一个可以从JSON反序列化的类。

然后,我将拥有多个业务类,如BookPrintBookEBook,以及继承层次结构。这些将具有多态Save方法等。

我会使用像AutoMapper这样的工具在数据传输对象和业务对象之间进行映射。

相关问题