Рисунок переводчика

Question

В предыдущем задании мой менеджер предложил использовать шаблон Translator для преобразования данных из DataTable в объекты. В принципе, класс Translator имел только статические (т.е. класс) методы, поэтому он был агрегацией вызовов функций. Мой первоначальный подход заключался в том, чтобы реализовать конструкторы для каждого объекта, которые могут принимать строку DataTable в качестве аргумента и создавать экземпляр, соответствующий данным.

Он сказал, что класс Translator был предложен Microsoft и обеспечил лучшую модульность кода. Я вижу этот момент, но в то же время он кажется очень не-OO-подход (хотя шаблон посетителя имеет схожие характеристики).

У вас есть этот образец, и что вы думаете об этом? за и против?

Answer 1

От C2.Com похоже, что шаблон переводчика представляет собой не-ООП реализации шаблона посетителя. Он отмечает и в конце статьи некоторые из недостатков, в том числе тот факт, что в семантике ООП трудно выразить (но не код), другими словами, она будет работать нормально, но может не иметь большого смысла, если вы используя чистый ООП для остальной части вашего кода.

Answer 2

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

Answer 3

Возможно, мне что-то не хватает, но почему бы просто не использовать linq?

IEnumerable<Customer> customerQuery = 
    from cust in customers 
    where cust.City == "London" 
    select cust; 

foreach (Customer customer in customerQuery) 
{ 
    Console.WriteLine(customer.LastName + ", " + customer.FirstName); 
} 

В любом случае, TranslatorPattern - это изменение структуры данных из одного представления в другую эквивалентную структуру. Здесь http://c2.com/cgi/wiki?TranslatorPattern - это более глубокая информация об этом.

Answer 4

Я думаю, вы говорите о Entity Translator. Я думаю, что переводчик в этом сценарии, естественно, является статическим методом. Там, где он живет, это вопрос эстетики. Он также должен быть легко протестирован в модуле, поскольку он должен иметь только зависимости от двух структур данных, которые он переводит. Вид звуков, подобных другому имени для их «контракта данных», - это DTO (объект передачи данных).