Здравствуйте, IT, Вы писали:

IT>Кстати, термин фасад, который вводится в обсуждаемой книжке так в общем-то и не прижился. А жаль.
Кому как. У меня, лично, и много где вполне прижилось.

IT>Есть в данной схеме одна небольшая нестыковочка. Если взять в качестве примера следующий интерфейс:

IT>

IT>public interface PersonService
IT>{
IT>    Person GetPersonByID(int id);
IT>}
IT>

IT>то здесь мы увидим использование объекта Person, который относится на самом деле к Business Entities. По схеме же Business Entities у нас спрятаны за фасадом.

IT>Бизнес сущности, они же Domain Entities, они же Data Transfer Objects (DTO).
В данном случае они вполне правы. Точнее могут быть вполне правы. Entities, которые работают внутри бизнес-логики сервера, и DTO, возвращаемые клиенту, могут сильно различаться как по формату (DTO — xml, Entities — объекты), так и по содержимому. Например в Entities содержатся секретные поля которые ни в коем случае не должны попадать, либо редактироваться клиентом. Или клиент может сам заказывать себе DTO, например с помощью нетипизированного DataSet, в то же время внутренняя логика должна оперировать полным состоянием entities. Вобщем тут сильно зависит от решения — есть ли явная трансформация из Entities в DTO или оного нет.