Я не видел эти конкретные лекции, но это, кажется, говорить с философией дизайна N-уровневой архитектуры, такие как MVC (используется обычно с ASP.Net) и MVVM (используется обычно с WPF). Идея в этом заключается не в том, что ваше представление не должно использовать пользовательские объекты, а просто то, что объекты, которые вы используете для моделирования ваших данных, не должны содержать много конкретной бизнес-логики, которая может измениться в зависимости от среды.
Например, если таблица в базе данных является , вы можете иметь объект под названием BillSummary с customer, date, subtotal, fees total, tax total, и grand total. Вы можете использовать уровень доступа к данным для извлечения данных из базы данных и создания объектов (причина этого в том, что вы можете легко изменить свой подход и создать различные классы доступа к данным для SQL Server, Oracle и веб-службы без изменения любой из вашего кода пользовательского интерфейса - пользовательский интерфейс не заботится о том, откуда появился объект, просто он получает тип объекта, который он ожидает).
Сам объект должен быть как можно более простым, чтобы вы могли легко передавать его назад и вперед между различными приложениями на разных платформах (например, приложение .NET, взаимодействующее с веб-службой Java или .Net-приложением, которое имеет мобильное приложение Xamarin, которое его поддерживает.) Чем больше пользовательских типов данных и встроенной логики вы используете, тем больше усилий вам, как правило, нужно разделить с объектом между разнородными проектами.
Если у вас есть код, который вычисляет сумму налогов и сборов, то это пример бизнес-логики. Он принадлежит другому слою (контроллер или viewmodel). Причина этого в том, что если вы перейдете в другую страну или регион, у вас могут быть разные виды сборов, требующие разных расчетов. Если вы это сделаете, вы можете заменить viewmodel без изменения кода пользовательского интерфейса или без изменения классов объектов (модели) или кода доступа к данным. Вы можете даже запускать разные контроллеры или режимы просмотра бок о бок для поддержки разных клиентов в зависимости от того, где они живут.
Итак, чтобы прервать погоню, не увидев лекцию, но исходя из того, что вы описываете, я думаю, что он означает, что ваш взгляд/пользовательский интерфейс должен ожидать только «объекты типа скелета», которые содержат основные поля данных. Вы можете привязать свой интерфейс к ним или использовать их в качестве инструмента для передачи данных с уровня на слой. Однако, чтобы максимизировать повторное использование и гибкость вашего кода, вы должны избегать использования кода, который связывается с базой данных или кодом, который реализует конкретную бизнес-логику в этих объектах модели. Когда он говорит о «специфичной для домена», я подозреваю, что он имеет в виду вещи, которые имеют отношение к тому, как организация хранит свои данные, бизнес-правила, которые организация имеет на месте, и т. Д. (Эти вещи принадлежат другим слоям.)
Это действительно зависит от того, насколько сложным является приложение, насколько велика команда разработчиков программного обеспечения. Если это очень простое приложение, нет проблем даже с непосредственным запросом базы данных в пользовательском интерфейсе, вместо добавления слоев лесов. – ZhongYu
Один шаблон может быть Model-View-ViewModel (MVVM). ViewModel представляет информацию, которая может представлять объекты модели домена в пользовательском интерфейсе (View). – chadnt
Вы можете использовать объекты передачи данных (DTO), которые в основном представляют собой контейнеры данных без какой-либо бизнес-логики. Затем уровень сервиса будет знать, как обрабатывать эти и, возможно, преобразовывать их в объекты домена.В зависимости от вашего пользовательского интерфейса DTO также могут быть отправлены в/из JSON (или другого формата) перед отправкой/получением с уровня презентации. –