Хотелось бы услышать комментарии к Архитектуре Класса, к которой я привык

Question

За время моей работы в качестве разработчика программного обеспечения я привык к созданию классов Entity (или DTO) и классов Manager. Например, я бы создал Customer с его методами получения и установки свойств, а затем CustomerManager со всеми методами, относящимися к классу Customer (например, GetCustomer, GetOrders и т. Д.). Не знаю почему, но мне показалось привлекательным иметь дополнительное разделение между свойствами и методами. Но теперь я начинаю думать, хорошо это или плохо. Я имею в виду, что я бы предпочел Customer.Get (), чем CustomerManager.GetCustomer (). Я хотел бы услышать ваши мнения и предложения по этому поводу. Являются ли различия чисто эстетическими или что-то можно извлечь из любого подхода?

Заранее спасибо, Сообщество в Stackoverflow всегда было очень полезным. Продолжайте в том же духе!

Answer 1

Я предпочитаю CustomerManager.GetCustomer() на основании того, что:

• это более понятное / самодокументируемое
• Customer.Get () ... получить что?
• разделение проблем ... клиенты сами не понимают:)

Для меня DTO является (или, по крайней мере, звучит так же, как) POCO;в обоих случаях это, по сути, пакет данных, в котором полноценный класс (в смысле OO, DDD, BL) выходит далеко за рамки этого.

И класс Customer, и класс CustomerManager могут иметьметоды и свойства, которые подходят в контексте области бизнеса / приложения, но DTO / POCO не на этом уровне.