Modele a encje z bazy danych (EFCore)

Ostatnio trochę poczytałem (tutaj i gdzie indziej) nt. zasadności i technik stosowania Repo, modeli a encji i jestem trochę w kropce (czyt. mam sieczkę w mózgu) w kwestii przełożenia DB - apka.
Przypuśćmy, że piszemy program którego jednym z zadań jest automatyczne wysyłanie maili. Używamy EFCore.
Mój podstawowy model to byłby Klient. Klient ma m.in. nazwę, adresy email, stosowane przywitanie, treść i zakończenie maila.
Bazę chciałbym zrobić wg. podejścia Code First (możę tu jest błąd?).
No i teraz tak - jeszcze niedawno bym zrobił po prostu modele: Customer, Intro, Body, Ending, Emails w taki sposób (odpowiadający tabelom w bazie):

class Customer
    {
        public string Name { get; set; }
        public virtual IntroDB Intro { get; set; }
        public virtual BodyDB Body { get; set; }
        public virtual EndingDB Ending { get; set; }
        public virtual ICollection<Mailbox> Emails { get; set; }
    }

class Mailbox
   {
       public string Address { get; set; }
       public virtual CustomerDB Customer { get; set; }
   }

class Intro
    {
        public int IntroId { get; set; }
        public string Name { get; set; }
        public int Content { get; set; }
    }

Body, i Ending analogicznie
Ale mnie tak teraz te skrawki wiedzy trafiły (pewnie w złe miejsca) i może jednak np. tak:

public class Customer
    {
        public string Name { get; set; }
        public ICollection<string> EmailAddresses { get; set; }
        public string Greeting { get; set; }
        public string Ending { get; set; }
        public string Body { get; set; }
        public ICollection<string> PhoneNumbers { get; set; }
    }

a do zrobienia bazy osobny folder (DBModels?) w którym by były modele jak w pierwszej wersji - z tego by się robiła baza, a ja poprzez odpowiednie repozytorium (repozytoria?) bym sobie pobierał/ edytował/ dodawał tych klientów. Robię sobie jednak w tym momencie problem gdy będę chciał umożliwić CRUDowanie treści (będę chciał)- dużo się będzie musiało dziać w VModelach (imho).

Byłoby mi bardzo miło jakbyście mi podpowiedzieli jak do takich zagadnień najlepiej podchodzić i wypomnieli wszystkie głupoty jakie w tym poście umieściłem.

P.S. Miałem też przygodę z osobnym projektem do tworzenia DB. Ale odepchnął mnie fakt konieczności tworzenia contextu w jednym i drugim projekcie, a następnie uaktualnianie równolegle obydwóch.

No jeśli te wszystkie Greeting, Body i Ending są takie przypisane 1:1 dla jednego klienta, to bez sensu raczej robić dodatkowe trzy tabelki i jakieś klucze obce do tego.
Podobnie z numerami telefonów i adresami email. Ale nie wiem, czy w EF da się mieć po prostu kolekcję stringów jako właściwość encji, raczej obstawiam, że trzeba mieć oddzielne klasy i tabele.
Potencjalnego problemu z viewmodelami nie rozumiem, nie wiem też po tu jakieś repozytoria. W ogóle to nawet nie wiem po co tu baza i EF.

Tak jak wspomniał @somekind, jeśli są to relacje 1:1 to nie tworzyłbym raczej tutaj dodatkowego nakładu pracy w postaci dodatkowych tabel.

Co do EF Core i kolekcji stringów jako typ encji - można tak zrobić oczywiście, ale wtedy musiałbyś w swoim Fluent API zrobić np coś takiego:

modelBuilder.Entity<Customer>()
            .Property(e => e.PhoneNumbers )
            .HasConversion(
                x => string.Join(',', x),
                x => x.Split(',', StringSplitOptions.RemoveEmptyEntries));

aczkolwiek nie jest to zalecana forma trzymania danych, chociażby ze względu na złożoność wyszukiwania po takich zagregowanych danych w jednej kolumnie.

Teksty do klientów to: 1 do N - jeden tekst może być używany do kilku Klientów,
Mail - klient to: N do 1 - klienci (firmy) mają często kilka adresów na które trzeba maile wysłać.
(telefonów nie chciałem w ogóle wklejać, ale też jest kilka na firmę)
W kwestii zasadności stosowania bazy - dojdą jeszcze takie rzeczy jak zapisywane oferty dla poszczególnych klientów, z persystencją ofertowanych produktów no i jeszcze występuje tu aspekt edukacyjny :)

A widzę teraz, że mój pomysł zaliczał się do tych raczej głupszych niż mądrzejszych ;)