Не могу найти лучший способ применения лучших методов проектирования кода в программном обеспечении - PullRequest
0 голосов
/ 03 июля 2018

[Pre]

Я должен сказать, что я тупой новичок, который пытается собрать вместе важные головоломки с такими важными деталями, как DDD, TDD, MVVM и EFCore. У меня около 10 лет опыта разработки окон в совершенно неправильной форме, и после того, как я присоединился к Plurasight, я понял, что только что потерял свои последние 10 лет, и это действительно печально:).

[Описание проблемы]

У меня есть приложение, которое я хочу переписать с нуля, используя новейшие и лучшие методики, которые были изучены за последние 6 месяцев на Pluralsight, но проблема в том, что эти новые знания мешают мне, потому что я просто боюсь, что я снова сделаю это неправильно ... (это глупо, я знаю, но это то, что есть).

Итак, возвращаясь к моим вопросам, у меня есть большая проблемная область и довольно хорошо документированная бизнес-логика, которую я должен включить в код. Я понимаю, что моей отправной точкой является уровень данных проектирования, для этих целей я хочу использовать ядро ​​Entity Framework (я видел курс Джулии Лерман по Pluralsight, и я думаю, что она удивительна и вдохновляет меня использовать EFCore в качестве ORM для моего приложения). Но в то же время утечка опыта порождает больше вопросов, чем то, что я узнал в Pluralsight, и я постараюсь написать их все (пожалуйста, не судите меня слишком сильно)

  1. Похоже, мне понадобится 2 или более проектов модели данных в моем решении, и вот почему у меня несколько типов наборов документов, каждый из которых содержит более одной справочной литературы, используемой для создания уникальных имена файлов и таблицы данных. Но мне кажется странным, что у нас есть 3 проекта модели данных, таких как MyApp.PackType1.DataModel, MyApp.PackType2.DataModel, и каждый из них будет предварительно установлен с помощью EFCore, и каждый из них создаст свою собственную базу данных на основе определенного контекста данных. по EF. Разве это не очень избыточно или это правильный путь?

  2. Я не понимаю, как объединить эти несколько проектов Data Models, включая Shared Kernel, в одну симпатичную модель

  3. Я не понимаю, как лучше спроектировать мои классы данных? Должны ли они быть просто POCO, или я могу сделать их классами с красивыми переменными и общедоступными свойствами? Каковы лучшие практики здесь?

  4. Также я не понимаю, каков наилучший способ использования шаблона MVVM в дополнение к этому, и применимо ли вообще использование MVVM в этом случае?

  5. Должен ли я хранить свои тесты в отдельных проектах, таких как MyApp.PackType1.DataModel.Tests, или хранить их в одном проекте? С наилучшими пожеланиями, Maks!

приписка

Прошу прощения за неясные определения и вопросы, английский не мой родной язык.

Ответы [ 2 ]

0 голосов
/ 03 июля 2018
  1. Хм, несколько DbContexts (моделей) обычно появляются, когда у вас есть разные базы данных, которые вы используете. Общее правило: один контекст = одна база данных. Исключения могут возникать, когда существует множество таблиц, которые можно сгруппировать функционально, но у этого подхода есть свои недостатки.
  2. DbContext - это шаблон репозитория, но для отдельных таблиц. Использование шаблона «Единица работы» и расслоение с настраиваемым поставщиком хранилища позволит вам «отобразить» его как единую базу данных, скрывая сложность от внешнего интерфейса.
  3. Ваши описания сущностей обычно создаются как прямые POCO. Вы можете проявить творческий подход с различными DTO
  4. В двух словах, шаблон MVVM выглядит следующим образом:
    • Запрос от пользовательского интерфейса к контроллеру
    • Контроллер, возможно, выполняет несколько вызовов на уровне данных для сбора данных
    • Сбор данных в одной ViewModel (все, что нужно странице)
    • Возврат к пользовательскому интерфейсу
    • Прелесть подхода в одном интерфейсе (запрос / ответ) для пользовательского интерфейса
  5. Отдельный проект на мой взгляд. Существуют способы подделки соединения с базой данных с помощью EF, поэтому вы не используете «живые» данные.

Эта статья CodeProject пригодится.

0 голосов
/ 03 июля 2018

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

  1. Вы можете иметь только одну модель для своих сущностей (DDD) и создать подмодель из этой модели в своих проектах конечного уровня (веб-API или пользовательский интерфейс)

  2. Точка считывания № 1

  3. Вы должны создать проект Entity Layer, который представляет вашу базу данных, а затем вы можете создавать DTO для конкретных сценариев

  4. С моей точки зрения, используйте Angular, но вы можете использовать другую инфраструктуру пользовательского интерфейса, такую ​​как React или VueJ, но я предпочитаю использовать Angular для создания интерфейсов пользовательского интерфейса и использования .NET Core Web API из клиента

  5. Создание модульных тестов и интеграционных тестов для ваших проектов Web API, а в качестве дополнительной функции вы можете использовать Db в провайдере памяти для тестов

Может быть это руководство полезно: https://www.codeproject.com/Articles/1160586/Entity-Framework-Core-for-Enterprise

Привет

...