Бизнес-правила, в основном

Это если придерживаться чистого кода

каждый сам решает что оправдано, что нет. Но я с опыта могу сказать, т.к. вот сейчас один из проектов запилен по такому принципу когда Entity реализует INotifyPropertyChanged и я могу с увереностью сказать, что выглядит это некрасиво

хм

а можно пример некрасивости из проекта?

нельзя ибо NDA, придется вам наслово поверить, хотя может вам такое и не покажется некрасивым

ну, может тогда в двух словах, что именно некрасиво? )

вот вам кейс, представьте что есть некая Entity с филдом FirstName LastName, реализует INotifyPropertychanged и она биндится на UI и заказчик захотел чтобы измененные филды на UI отображались Italic фонтом например. Подумайте как это реализовать.

через Dto )

кто пишет на WebAPI на .NET Core? помогите разрбраться, в общем, встала задача сделать логгирование изменений сущностей, в когде я извлекаю "старое" значение, до применения .SaveChangesAsync, потом сравниваю с новым, уже после .SaveChangesAsync, и создаю запись в базу через .SaveChangesAsunc сущности аудита. Так вот, коллега утвержает, что .SaveChangesAsync должен быть один. А я всегда, когда работал с логгированием не через базу, и не через EF, то есть вручную - использовал по 3 запроса в одной транзакции, что по моему разумению вполне соотвествует чтению состояния объкта из базы (если не закеширован), обновлении полей обьекта логгирования и записи измененного обьекта в базу. Зачем нужно именно один раз вызывать .SaveChangesAsync и что в этом такого криминального, если исользовать два - один для обьекта EF, другой для обьекта EF, его логгирующего?

зачем вам Dto и ViewModel по вашей логике это ненужная дубликация кода, Entity будет достаточно :)

не не, стоп

если нет причин - то эта дупликация кода ненужная
вы явно обрисовали причину, и именно для таких вещей Dto - явный кандидат

я никогда не утверждал, что Dto - это зло и вообще фу))

ну тогда вам нужно было уточнить что ваш кейс когда Entity делает все, подходит только для приложений уровня Hello World

нет, не только

ок

Зачем использовать 2 транзакции, если 2я должна быть неразрывно связана с 1й?

стандартные кейсы редактирования данных (вот у нас форма, внесите данные) - вещь распространённая, и намного проще её организовывать с моделью напрямую, а если модель находится в контексте с трекером, то отслеживание изменений и сохранение становятся вещами одной строки

И последний комментарий по этой теме. Вы никогда не можете знать наверняка, что вам понадобится в будущем, изначально может быть так что причин нет, а потом в какой-то момент причины появятся и тут вы встрянете по полной программе, учитывая что у вас уже тонна кода написана. Поэтому умные люди и придумали абревиатуры типа SOLID которым нужно придерживаться при разработке, чтобы потом не попасть.

Для таких "стандартных кейсов" делается кодогенерация. Один раз.

В реальной жизни правила редактирования немного сложнее.