Фасад против Посредника
Ваша проблема двоякая:
- У вас нет класса, определенного на корневом уровне. Структура класса должна соответствовать целому JSON, вы не можете просто десериализовать из середины.
- Всякий раз, когда у вас есть объект, ключи которого могут измениться, вам нужно использовать
Dictionary. Обычный класс не будет работать для этого;
Сделайте ваши классы такими:
class RootObject
{
[JsonProperty("results")]
public Results Results { get; set; }
}
class Results
{
[JsonProperty("jobcodes")]
public Dictionary JobCodes { get; set; }
}
class JobCode
{
[JsonProperty("_status_code")]
public string StatusCode { get; set; }
[JsonProperty("_status_message")]
public string StatusMessage { get; set; }
[JsonProperty("id")]
public string Id { get; set; }
[JsonProperty("name")]
public string Name { get; set; }
}
Затем выполните десериализацию следующим образом:
RootObject obj = JsonConvert.DeserializeObject(json);
3 ответа
... большинство сайтов указывает что посредник “adds functionality”...
фасад только выставляет существующую функциональность от другой точки зрения.
посредник "добавляет" функциональность, потому что она комбинирует другую существующую функциональность для создания новой.
Берут следующий пример:
у Вас есть система регистрации. От той системы регистрации можно или зарегистрироваться в файл в сокет, или к базе данных.
Используя шаблон разработки фасада Вы "скрыли" бы все отношения от существующей функциональности позади единственного "интерфейса" тот, который выставляет фасад.
Клиентский код:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
реализация может включить взаимодействие многих объектов. Но в конце, уже существует функциональность. Вероятно, метод "отладки" реализован следующим образом:
Реализация:
class Logger {
private LoggerImpl internalLogger;
private LoggerManager manager;
public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}
public void debug( String message ) {
this.internalLogger.debug( message );
}
}
функциональность уже существуют. Фасад только скрывает его. В этом гипотетическом случае LoggerManager обрабатывает создание корректного регистратора, и LoggerImpl является пакетом частный объект, который имеет метод "отладки". Таким образом, Фасад не добавляет функциональность, которую он просто делегирует к некоторым существующим объектам.
В другой руке посредник добавляют новую функциональность путем объединения различных объектов.
Тот же Клиентский код:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
Реализация:
class Logger {
private java.io.PrintStream out;
private java.net.Socket client;
private java.sql.Connection dbConnection;
private String loggerName;
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}
}
public void debug( String message ) {
if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
}
В этом коде, посредник является тем, который содержит бизнес-логику для создания соответствующего "канала", чтобы зарегистрироваться и также превратить журнал в тот канал. Посредник "создает" функциональность.
, Конечно, существуют лучшие способы реализовать этот полиморфизм использования, но точка здесь должна показать, как посредник "добавляет", новая функциональность путем объединения существующей функциональности (в моем образце не показал, что очень много извините), но вообразите посредника, считайте из базы данных удаленный хост, где зарегистрировать, затем создаете клиент, и наконец запишите в тот клиентский поток печати сообщение журнала. Таким образом, посредник "посредничал" бы между различными объектами.
Наконец, фасад является структурным шаблоном, который является им, описывает состав объектов, в то время как посредник является поведенческим, то есть, он описывает способ, которым взаимодействуют объекты.
я надеюсь, что это помогает.
Я думал, что различие было направлено: фасад является односторонней коммуникацией между клиентом и фасадом; посредник может быть двухсторонним разговором с сообщениями, текущими назад и вперед между клиентом и посредником.
Я использую посредника для добавления функциональности файла журнала.
Это работает как это:
- Obj A говорит посреднику, что требуется что-то сделанное.
- посредник отправляет сообщение в различные объекты клиента.
- Obj B делает вещь Obj потребности и передает соответствующее сообщение обратно через посредника.
- Между тем, Obj C также отправляется и сообщения посредника и регистрирует результаты. Тем путем мы можем получить пользовательскую статистику от файлов журнала.
- Obj D мог быть ошибочным средством проверки также, так, чтобы, если Obj B отвечает, что запрос Obj A невозможен, Obj, D мог быть вещью, которая сообщает об этом пользователю. Ошибки могут теперь быть зарегистрированы другой файл, чем регулярное действие и могли использовать некоторые другие средства вести себя (подача звукового сигнала, безотносительно), что Obj A не должен действительно интересоваться.
-
1