Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Еще раз повторю: проекты валятся не из-за того, что в 10 местах переменную переименовать нужно, а из-за того, что в БЛ в в том виде в котором она реализована, становится невозможно вносить изменения, а баги начинают жить вечно. Это вопрос собственно какую ценность мы выбираем: проект или код в котором не нужно менять в трех местах переменную. Это чисто "житейский" подход, что мы отделаем главное от не главного, а код здесь вторичен. 
S>Давай на примерах рассмотрим.
Q>>P.S. Я это видел на практике, один объект везде, что-то типа такого:
Q>>
Q>>class Customer: Entity
Q>>{
Q>> [NoMapper] - что это здесь делает?
Q>> strring property{get;set;}
Q>> DateTime DateTime {get;set;}
Q>> string FomratDateTime
Q>> {
Q>> returt DatetTim.Format - //возвращаем в нужном формате
Q>> }
Q>>}
Q>>
S>Т.е. вам не нравится что в одном классе лишние поля, часть из которых не нужна для конкретного слоя? А что если добавить методы-расширения или mixin, чтобы нужные для конкретного слоя поля были в этом слое?
А ради чего дрючиться, ради какой такой святой цели? Что бы с "оптимизировать" код который имеет низкую ценность и вообще ни на что не влияет?
А как быть с вот таким ответом из БЛ:
class CustomerCarTuple: ValueObject
{
public Customer Customer {get;private set}
public Car Car {get;private set}
}
//метод сервиса
public Ienumerable<CustomerCarTuple> GetCustomerCarReport()
{
//
returt ...
}
