Budowa obiektu biznesowego

Witam,
Zastanawiam się nad tym, czy obiekt biznesowy, który jest wykorzystywany np. w View modelach powinien być zawsze obiektem prostym czy może być (lub powinien być) złożonym. Poniżej 2 uproszczone przykłady. Cel: zaktualizować obiekt:

Wersja 1:

 
    public class Customer_V1
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Status { get; set; }
    }

    public class MainViewModel
    {
        ICustomerRepository _customerRepository;

        public MainViewModel(ICustomerRepository customerRepository)
        {
            _customerRepository = customerRepository;
        }

        public Customer_V1 SelectedCustomer_V1 { get; set; }

        private async void UpdateCustomer_V1()
        {
            try
            {
                SelectedCustomer_V1.Status = "In progress";
                await _customerRepository.UpdateCustomerAsync(SelectedCustomer_V1.ID, SelectedCustomer_V1.Name);
                SelectedCustomer_V1.Status = "Done";
            }
            catch(Exception exception)
            {
                SelectedCustomer_V1.Status = "Error";
                MessageBox.Show(exception.Message);
            }
        }
    }

Wersja 2:

 
    public class Customer_V2
    {
        ICustomerRepository _customerRepository;

        public Customer_V2(ICustomerRepository customerRepository)
        {
            _customerRepository = customerRepository;
        }

        public int ID { get; set; }
        public string Name { get; set; }
        public string Status { get; set; }

        public async void UpdateCustomerAsync()
        {
            try
            {
                Status = "In progress";
                await _customerRepository.UpdateCustomerAsync(ID, Name);
                Status = "Done";
            }
            catch
            {
                Status = "Error";
                throw;
            }
        }
    }

    public class MainViewModel
    {
        public Customer_V2 SelectedCustomer_V2 { get; set; }

        private void UpdateCustomer_V2()
        {
            try
            {
                SelectedCustomer_V2.UpdateCustomerAsync();
            }
            catch (Exception exception)
            {
                MessageBox.Show(exception.Message);
            }
        }
    }

W pierwszym przykładzie widać, że klasa jest bardzo prosta. Nie ma zależności. Jednak przykład wykorzystania pokazuje, że użytkownik tego obiektu musi troszczyć się o jego aktualizację.

W drugim przykładzie klasa jest bardziej złożona, ma zależności, udostępnia metodę / metody, ale jej wykorzystanie jest bardzo proste.

Czy oba te podejścia są poprawne (i należy wybrać odpowiedni) czy może któryś z nich (konkretnie chodzi mi o drugi przypadek) jest zły, a zależności nie można wstrzykiwać w tego typu obiekty? Co mówią wzorce na ten temat? Proszę o wyjaśnienie lub ew. linki.

Z góry dzięki.

Jest coś takiego jak Naked Object. Jego stosowanie polega na pracy z obiektami biznesowymi zawierającymi logikę (rozumianą zgodnie z Domain Driven Design). Jest to całkiem dobre rozwiązanie, bo ogranicza ilość warstw oraz pozwala na rozsądne przypisanie odpowiedzialności. Inna sprawa to jakie będą zależności, bo to z przykładu jest hm... nie do końca OK.

Dzięki wielkie za odpowiedź.
A jakiego typu zależności powinny być w tego typu klasach wstrzykiwane?

Na przykład związane z zakresem odpowiedzialności danego obiektu.

Sprzedawca wystawia fakturę

Czyli sprzedawca ma zależność do jakiegoś systemu do wystawiania faktur. Samo zarządzające się encje to taka trochę na siłę robiona implementacja Active Record.

Dzięki wielkie za odpowiedzi.

Łapka w górę.