Design Pattern - Fat адаптер

Question

Мы реализовали шаблон проектирования адаптер, работа которого заключается в следующем:

1. Закон в качестве связующего звена между обслуживания и доступа к данным слоев.
2. Преобразование необработанных данных (из источника данных, внутреннего или внешнего) в данные, относящиеся к домену. Сделайте необходимую проверку и массирование.
3. Иногда выполнение DAO-вызовов может зависеть от данных, которые не могут быть доступны из входных параметров, или, возможно, потребуется сделать дополнительные служебные вызовы на основе входных данных. Другими словами, адаптер не всегда может выполнять сопоставление 1: 1 между службой и DAO. Он может отображать один и тот же вызов из службы в разные вызовы DAO на основе входных параметров.

Пункт №3 начинает беспокоить меня, поскольку адаптеры становятся все более сложными, чем я изначально представлял. Я не знаю шаблона проектирования, чтобы обрезать адаптер. Есть ли это? Предложения?

Answer 1

Вы использовали то, что мне нравится называть «швейцарским армейским ножом».

• Пункт 1 является broker pattern (или аналогичный)
• точка 2 является adapter pattern (или аналогичный)
• Пункт 3 является content based routing (или аналогичный)

Лучшая практика говорит, что вы должны разбить класс по крайней мере в 3 класса, по одному для каждой проблемы.

Answer 2

Вместо использования адаптера или полного репозитория (операции CRUD) я бы использовал интерфейс IReader для чтения и шаблона посетителя для удаления вставки update, поэтому вы можете отделить логику домена от деталей инфракрасной (persistance), здесь идея:

public class MyBusinessObject : IAcceptBusinessVisitor, IAcceptMyBusinessIdVisitor 
{ 
    private readonly string _id; 

    private string MyPrivateProp { get; set; } 
    //Fully encapsulated object 
    public MyBusinessObject(string id, string myPrivateProp) 
    { 
     _id = id; 
     MyPrivateProp = myPrivateProp; 
    } 

    public void UpdateMyProp(string newProp) 
    {    
     if (string.IsNullOrWhiteSpace(newProp)) throw new ArgumentNullException(nameof(newProp)); 
     //Business rules ... 
     MyPrivateProp = newProp; 
    } 

    public void Accept(IMyBusinessObjectVisitor visitor) 
    { 
     if (visitor == null) throw new ArgumentNullException(nameof(visitor)); 
     visitor.Visit(_id, MyPrivateProp); 
    } 

    public void Accept(IMyBusinessIdVisitor visitor) 
    { 
     if (visitor == null) throw new ArgumentNullException(nameof(visitor)); 
     visitor.Visit(_id); 
    } 
} 

public interface IAcceptBusinessVisitor 
{ 
    void Accept(IMyBusinessObjectVisitor visitor); 
} 

public interface IAcceptMyBusinessIdVisitor 
{ 
    void Accept(IMyBusinessIdVisitor visitor); 
} 

public interface IMyBusinessObjectVisitor 
{ 
    void Visit(string id, string prop); 
} 

public interface IMyBusinessIdVisitor 
{ 
    void Visit(string id); 
} 

public class SavePersistanceVitor : IMyBusinessObjectVisitor 
{ 
    public void Visit(string id, string prop) 
    { 
     //Save to Database 
    } 
} 

public class UpdatePersistanceVitor : IMyBusinessObjectVisitor 
{ 
    public void Visit(string id, string prop) 
    { 
     //Update to Database 
    } 
} 

public class DeleteVitor : IMyBusinessIdVisitor 
{ 
    public void Visit(string id) 
    { 
     //Delete in Database 
    } 
} 

здесь для чтения:

public interface IMyBusinessObjectReader 
{ 
    MyBusinessObject Read(string id); 
} 

class MyBusinessObjectReaderFromDb : IMyBusinessObjectReader 
{ 
    public MyBusinessObject Read(string id) 
    { 
     //Read from database 
     string myPrivateProp = ""; 
     return new MyBusinessObject(id, myPrivateProp); 
    } 
} 

следующим шагом может быть добавление дженерики для чтения и посетителей. В этом случае вы получаете небольшие классы и получаете гибкость и преимущества от твердых принципов, таких как единая ответственность, сегрегация интерфейса и т. Д. Таким образом, вы можете создать богатый инкапсулированный домен и расширить его функциональность с помощью некоторых принципов. С уважением!