#nhibernate #fluent-nhibernate #domain-driven-design #sharp-architecture
#nhibernate #свободно-nhibernate #дизайн, управляемый доменом #sharp-архитектура
Вопрос:
Я изучаю архитектуру sharp и увидел, что она фактически передает объекты на другой уровень (что касается уровней представления). Разве это не должно предоставлять интерфейсы объектов, чтобы сделать их более слабо связанными? Или я что-то упускаю?
Комментарии:
1. Можете ли вы привести пример кода, который вы имеете в виду?
Ответ №1:
Я считаю, что вы можете использовать DDD многими способами, и самое важное — это реально взглянуть на потребности вашего проекта и ситуацию. Если вы будете применять DDD на asp.net Веб-приложение MVP или MVC и приложение the, вероятно, не будут взаимодействовать с другими внешними системами. Тогда может быть излишним использовать уровень обслуживания и объекты DTO только для того, чтобы уровень представления ничего не знал о домене. Наиболее важным является то, что вы скрываете / удаляете информацию о создании объектов, логике домена и возможностях перевода объектов в недопустимое состояние. Всего этого можно достичь с помощью хорошего API объектов домена. Тогда я чувствую, что хорошей практикой может быть отправка объектов на уровень присутствия. Вы также можете использовать репозитории для загрузки объектов в классы вашего контроллера / презентатора на уровне представления. Если вы посмотрите на множество примеров DDD, вы обнаружите, что люди стремятся к тому, что подходит им лучше всего. Я никогда не видел ни одного примера и практики, где вы предоставляли бы свои объекты с интерфейсами. Вы можете многого достичь, используя только внутренние атрибуты, защищенные и доступные только для чтения. Это скроет возможности api для уровня представления.
/ С наилучшими пожеланиями, BacceSR