Блог

Я пытаюсь реализовать проект чистой архитектуры с нуля, следуя Microsoft ASP.NET рекомендации по архитектуре и их примерный проект eShopOnWeb.

Объекты EF в моем случае сначала являются базой данных. Для этого я использовал Scaffold-DbContext инструмент, но, похоже, он не позволяет указывать базовый класс для сгенерированных объектов. Обычно это не проблема (я думаю), но проект eShopOnWeb, похоже, имеет BaseEntity суперкласс для всех своих объектов.

Мои вопросы —

1. Должен ли я беспокоиться о том, что все объекты вообще расширяют базовый класс? Что, если я просто использую объекты как есть (я в этом немного новичок, поэтому, возможно, мне не хватает чего-то очень простого)? В случае, если базовый класс — это правильный путь, существует ли «официальное» решение для создания объектов с предопределенным базовым классом?
2. eShopOnWeb — официальный пример приложения Microsoft — использует подход code first к БД. Означает ли это, что это официальная рекомендация Microsoft в отношении лучших практик? Я немного опасаюсь этого, потому что при таком подходе я не уверен, как можно выполнить оптимизацию и тонкую настройку базы данных (индексы и все другие специфические для базы данных вещи) и т. Д.

Объектам не нужно расширять базовый класс. Я использую их только в системах, где у меня есть действительно общие поля для некоторых / большинства объектов, таких как «EditableEntity», где я мог бы поместить общие поля, такие как CreatedBy, createdAt, ModifiedBy, ModifiedAt, RowVersion. Например, я не использую базовый класс для «Id», потому что часто бывают случаи использования другого идентификатора или принятия составного идентификатора для определенных таблиц.

В большинстве примеров используется Code-First просто потому, что он использует код для настройки схемы, и это то, что, как они ожидают, разработчики поймут, а не SQL. IMO это здорово для быстрого запуска и запуска чего-либо, но в долгосрочной перспективе я нахожу, что это больше проблем, чем того стоит. (Возитесь с настройкой миграции вручную, как только вы дойдете до точки, где важна целостность данных БД.) Лично я никогда не использую его, потому что я пришел с опытом работы с SQL и ORM до code-first, поэтому мне удобнее думать о коде на стороне схемы и использовать явное сопоставление, чтобы точно знать, как EF будет интерпретировать эту схему. Полезно понимать, как работают code-first и миграции, но если вам удобно строить схемы, тогда DB-first подойдет. В игру вступают лучшие практики, связанные с изучением того, как эффективно сопоставлять отношения и запрашивать данные. Т.е. Использование .Select() , вероятно, является наименее изученным аспектом полного использования Entity Framework.