Entity Framework Core и REST клиент - организация кода

Question

Я строю решение с тремя проектами:

• .Data (содержит базовые классы Entity Framework и Writer.cs)
• .ConsoleApp (запуск проекта,звонки Writer.cs)
• .CloudTalker (ссылки на веб-службы и Fetcher.cs)

Цель решения состоит в том, чтобы вызывать API REST, получать объекты из API и хранитьих в базе данных, используя Entity Framework Core.Весь код работает нормально, но я уверен, что есть способы улучшить архитектуру.

Пример потока кода для получения клиентов из API REST и записи в базу данных:

1. Program.cs в .ConsoleApp создает Writer.cs и вызывает метод WriteCustomers().
2. WriteCustomers получает последнюю дату изменения для Клиентов в базе данных
3. WriteCustomers, звонит GetCustomers( latestModifiedDate ) в Fetcher.cs в проекте CloudTalker.Этот метод возвращает массив Customers (класс, возвращаемый API REST, а не Entity Framework).
4. WriteCustomers проходит через массив, преобразует REST-объект в EF Core-объект и помещаетв _context.Customers.
5. Context.SaveChanges() хранится Customers в базе данных.

Теперь к моим вопросам / призывам к мнению:

• Я сделал приличное разделение проблем?Меня беспокоит то, что либо CloudTalker должен знать о классах EF, либо классы EF должны знать о классах REST.Какой способ предпочтительнее?Должен ли CloudTalker.Fetcher.GetCustomers( lastModifiedDate ) возвращать объекты из классов EF или типа REST?
• Как мне обращаться с именами классов?Прямо сейчас у меня есть два Customer - вид REST и вид EF.Не красиво.
• Что-нибудь еще, что я должен сделать по-другому?

Заранее спасибо за то, что поделились своими мыслями.

Answer 1

Мне кажется, что это должно принадлежать сайту codereview, но вот что я думаю об архитектуре (я игнорирую тот факт, что это может быть простой проект, который может жить с быстрым и грязным решением)

Автор должен находиться в отдельном проекте и должен знать только об EF и DB. Сборщик должен знать только о REST и о том, как вызывать удаленные службы.Затем вы можете представить сервисный уровень, который знает о двух бывших бриках и вызывает сборщик данных для получения данных, а затем передает данные разработчику.

Я предполагаю, что нет бизнес-логики, поэтому нет необходимости в отдельном доменном проекте.Ваш сервисный уровень может быть непосредственно в вашем UI / Console проекте.

Что касается именования, как насчет CustomerReadModel, CustomerWriteModel?

Похоже, вам также нужно читать из БД, чтобы получить последнюю модификациюдата, поэтому я бы предложил иметь читателя где-нибудь в вашем проекте БД.