Czesc
Czy da się to jakoś pozenic?
Czy view model może być zewnętrzną warstwą w onion architecture?
Jak to razem połączyć?
Czesc
Czy da się to jakoś pozenic?
Czy view model może być zewnętrzną warstwą w onion architecture?
Jak to razem połączyć?
No ale jaki masz z tym problem?, nie rozumiem...
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
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
Tak, zgadzam się w 100%, nie ma lepszego wyjścia.
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ę
Najprościej (nie najbardziej idealnie) to po prostu robisz tak:
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.
Może to ciebie zainspiruje : https://pbs.twimg.com/media/DQZAmbdVoAAdP9A.jpg
Co o tym sądzisz?