MVVM i onion architecture

0

Czesc
Czy da się to jakoś pozenic?

Czy view model może być zewnętrzną warstwą w onion architecture?

Jak to razem połączyć?

0

No ale jaki masz z tym problem?, nie rozumiem...

0
Enter Name napisał(a):

No ale jaki masz z tym problem?, nie rozumiem...

Jak wpasować cebulę do MVVM?
Gdzie utworzyć bootstrap dla ioc kontrolera?

Jak np Ty to widzisz

0

Gdzie utworzyć bootstrap dla ioc kontrolera?

Wszystkie problemy rozwiążą się kiedy ściągniesz sobie Prism Templates, dodatek do VS, który dostarcza predefiniowane szablony projektów. Po co wymyślać koło od nowa?

https://marketplace.visualstudio.com/items?itemName=BrianLagunas.PrismTemplatePack

0

Tak, zgadzam się w 100%, nie ma lepszego wyjścia.

0

Dlaczego chcesz mieszać dwie architektury?

0
donPietro napisał(a):

Dlaczego chcesz mieszać dwie architektury?

Bo chce połaczyć jakoś MVVM z logika biznesową

z tego co się zaznajomiłem z MVVM - MODEL

Business logic is typically kept separate from the model, and encapsulated in other classes that act on the model. This is not always true: for example, some models may contain validation.

I chciałbym ogarnąć logike biznesową, która wystawia API, które konsumuje MODEL z MVVM - nie wiem czy to dobry trop, ale na razie tak chcę

0

Najprościej (nie najbardziej idealnie) to po prostu robisz tak:

  • jeden projekt, który zawiera modele
  • drugi projekt, który zawiera api (może też zawierać całą infrastrukturę, chociaż to też może być w osobnym projekcie)
  • kolejny projekt, który zawiera widoki

Pseudokod:

MyApp.Models

public class Person
{
  public ulong Id {get; set;}
  public string FirstName { get; set;}
  public string LastName { get; set; }
}

MyApp.API

public interface IPersonView
{
  void ShowPerson(Person p);
  Person GetPerson();
}

public class PersonController
{
  public Person GetPerson(ulong personId)
  {
    return db.GetPersonById(personId);
  }

  public void ShowPersonView(Person p, IPersonView view)
  {
    view.ShowPerson(p);
  }
}

Tak to w skrócie mniej więcej może wyglądać. Chociaż w rzeczywistości w metodzie ShowPersonView prawdopodobnie będziesz tworzył IPersonView za pomocą jakiejś fabryki.
Trochę inaczej będzie to wyglądało w zależności, czy robisz desktopa, czy może WebAPI, czy stronę internetową, ale zasada jest analogiczna. Tylko inaczej może się zachowywać kontroler. Tu akurat mam jeszcze tak, że Model jest jednocześnie ViewModelem. w MVVM jest to rozdzielone.

Generalnie co do logiki biznesowej, to powinieneś mieć jeszcze jedną warstwę - serwisy. Wtedy kontroler powinien wyglądać jakoś tak:


//interfejs do serwisu personów :)
public interface IPersonService
{
  bool AddPerson(Person p);
  Person GetPersonById(ulong id);
  void DeletePerson(Person p);
}

//serwis może wyglądać tak:

public class PersonService: IPersonService
{
  List<Person> db = new List<Person>();
  public bool AddPerson(Person p)
  {
    if(string.isNullOrWhitespace(p.FirstName)
        return false;

    ulong id = db.Last().Id + 1;
    p.Id = id;
    db.Add(p);
  }

 //itd
}


//i wtedy kontroller powinien wyglądać tak:
public class PersonController
{
  IPersonService personService;

  public PersonController(IPersonService service)
  {
    personService = service;
  }

  public void AddPerson(Person p)
  {
     personService.AddPerson(p);
  }
}

Żeby było jeszcze lepiej, to możesz oddzielić service od bazy danych. Wtedy tworzysz sobie repozytorium i w serwisie posługujesz się repozytorium zamiast tej list (lista wtedy jest w repozytorium). Dzięki temu masz jeden serwis z logiką biznesową i możesz mieć wiele źródeł danych (jedno repozytorium - jedno źródło danych). Oczywiście podczas stosowania ORMów repozytoria są lekko bez sensu, bo sam ORM pełni wtedy rolę w pewnym sensie repozytorium.

Pamiętaj, że w kontrolerach nie powinno być logiki. Kontrolery powinny być małe i lekkie i przesuwać całą robotę do serwisów.

0

Może to ciebie zainspiruje : https://pbs.twimg.com/media/DQZAmbdVoAAdP9A.jpg
Co o tym sądzisz?

1 użytkowników online, w tym zalogowanych: 0, gości: 1