Architektura systemu

0

Zgodnie z życzeniem osobny wątek (nie wszyscy zgadzali się z moimi wyborami).

Potrzebuję stworzyć nowe rozwiązanie ponieważ poprzednie napisane w Delphi nie do końca mi się sprawdziło.
Nowe chcę napisać w c#.
Ogólnie ma to być system (celowo nie aplikacja nie program aby nie było ograniczeń)
Ma to być system finansowo księgowy pracujący maksymalnie w sieci lokalnej (max VPN).
Dokumenty mają być dostępne dla innych systemów(tworzenie, edycja dokumentów księgowych przez inne systemy).
Jako pierwsze chcę stworzyć jądro systemu czyli Dokumenty i PlanKont(Plan kont poza jądrem ma być tylko do odczytu/prezentacja);

Założenia wstępne ale nie ostateczne.
Baza Postgresql (w dalszej kolejności możliwość pracy na innych).
Pluginy MEF ale też nie ostatecznie.
Oczywiście nie oczekuje kodu itd., a nakierowania.

0

Dobrze, a gdzie tu widzisz miejsce na pluginy?
I pytanie drugie, aczkolwiek ważniejsze - to ma być dekstop czy web?

0
somekind napisał(a):

Dobrze, a gdzie tu widzisz miejsce na pluginy?

Główna applikacja to tylko do wczytania pluginów.
Dokumenty w pluginach.

Pluginy zawczasu, wszystkie dodatkowe funkcjonalności mają być w pluginach.
Część ma być dostępna z menu, a część nie.

somekind napisał(a):

I pytanie drugie, aczkolwiek ważniejsze - to ma być dekstop czy web?

DeskTop

0

A jakie zalety użycia desktopa widzisz?
I czy logika ma być w tych pluginach instalowanych w aplikacjach desktopowych, czy może być centralny serwer wystawiający API, z którego będą korzystały aplikacje klienckie?

0
somekind napisał(a):

A jakie zalety użycia desktopa widzisz?

Bezpośredni dostęp do sprzętu (skanowanie, rozpoznawanie dzwoniącego numeru clip... to tak na przyszłość)

somekind napisał(a):

I czy logika ma być w tych pluginach instalowanych w aplikacjach desktopowych, czy może być centralny serwer wystawiający API, z którego będą korzystały aplikacje klienckie?

Tam gdzie będzie pracowała aplikacja dostępne są serwery linuksowe(administrowane przeze mnie).
Może być centralny serwer, chociaż wolałbym pierwsze podejście.

0

Przepraszam, że się upominam, mógłbyś dać znać czy jesteś zajęty.

A może inni mają jakieś propozycje?

0

Ok, w skoro istnieje potrzeba komunikacji ze sprzętem, to wybranie desktopa jest uzasadnione.
A co Ty tak właściwie chcesz wiedzieć?

0

Architektura.
Czy MEF to dobry wybór?
Jak zrobić całość aby spełnić wymagania.
Jak udostępniać dokumenty poza system (Serwer Automatyzacji może co innego).
Użyje prawdopodobnie NHibernate. Ale czy to dobry wybór.

Ja po prostu nie wiem co jest dostępne w NET?
W Delphi użyłem Pakietów i dokumenty były udostępniane poza system jako serwer automatyzacji. W Net może można to zrobić inaczej lepiej.
I w zasadzie najważniejsze jak to się robi w dużej skali (przez duże firmy)?

0

W C# może być ciężko o aplikację desktopową na linuxach. Mono wchodzi w grę, ale to może okazać się strzałem w stopę.

0

Nie nie to ma być dla Windows, w biurach w zasadzie nie używa się Linux-a.
Głównym powodem w Polsce jest Płatnik i Office oraz ignorancja.

0

Pytanie na temat architektury.
We wzorcu MVC model nie powinien nic wiedzieć na temat tego skąd pochodzą jego dane i w jaki sposób jest on zapisywany, a tym bardziej gdzie.
Jak w takim razie pogodzić NHibernate i MVC?
Czy dobrym podejściem będzie oddzielna klasa reprezentująca dane, które są na początku zapisywane do modelu przez fabrykę podczas tworzenia, a następnie przy zapisywaniu wyciągane z modelu i zapisywane tam gdzie trzeba (pewnie do bazy). Model pracuje tylko na tej klasie danych.
Jak to zgrabnie zautomatyzować?
Dodatkowo Ja mam model dostępny jako interfejs i tutaj Rodzi się następne pytanie jak zrealizować Widok dla takiego dokumentu zakładając, że nie zawsze widok będzie potrzebny i do tego model nie może wiedzieć nic o widoku.
Model musi być dostępny na zewnątrz systemu i być jednolitym "obiektem" ALL IN ONE.
Jak to się robi w dużych aplikacjach. Do tej pory robiłem to tak Model zawierał metodę SHOW(Interfejs), która tworzyła widok, podpinała zdarzenia pod kontrolki itd. Czy wy też to robicie?

0

MVC powinien mieć dostęp do warstwy modelu (DDD, jakiś service czy coś tam innego). MVC wywołuje metody z np. Service a to Service wie o tym, że jest NH czy EF czy jakiś inny dostawca danych.
Jak zapakujesz model w osobną Assembly, serwisy czy DDD też w osobnych to nie ma znaczenia czy używasz "sytemu" z poziomu MVC, testów czy webapi dla mobilnych.

0

Widok o modelu tak, ale nie w drugą stronę.
Gdzie ma być tworzony widok? I w jaki Sposób?

0

Widok z MVC ma być tworzony (czy raczej zwracany) przez kontroler. Widok w sensie ViewModelu zwykle przez jakąś metodę biznesową (service).
Masz metodę Index w kontrolerze

public ActionResult Index()
{
    List<DocumentViewModel> docs = documentService.GetDocuments();
    return View(docs);
}

Jeśli DocumentService będzie miał metody w rodzaju Add, Get, AddDocumentPosition itp to taki serwis możesz wykorzystać w różnych miejscach systemu nawet do udostęniania dokumentów (ViewModeli albo DTO dokumentów ) poza "system" dla różnych klientów (WinForms, webapi, mvc).

0

po co widok ma cokolwiek wiedziec o modelu?

WIdok wie o Controlerze
Controler wie o widoku i modelu (ma interfejsy udostepnione dla modelu, a widok uzywa kontrolera takze tylko zwraca wartosci))
model wie o biznesowej logice. Nie potrzebuje on wiedzy o controllerze (no moze poza kontraktami)

0
jacek.placek napisał(a):

Widok z MVC ma być tworzony (czy raczej zwracany) przez kontroler. Widok w sensie ViewModelu zwykle przez jakąś metodę biznesową (service).
Masz metodę Index w kontrolerze

public ActionResult Index()
{
    List<DocumentViewModel> docs = documentService.GetDocuments();
    return View(docs);
}

Jeśli DocumentService będzie miał metody w rodzaju Add, Get, AddDocumentPosition itp to taki serwis możesz wykorzystać w różnych miejscach systemu nawet do udostęniania dokumentów (ViewModeli albo DTO dokumentów ) poza "system" dla różnych klientów (WinForms, webapi, mvc).

Zakładam że DocumentService to moja fabryka dokumentów, to nie do końca to.
Załóżmy że udostępniam interfejs IDokument za pomocą serwera automatycaji i na zewnątrz systemu dostaję interfejs który nie ma widoku i koniec.
Czy można byłoby prosić ponownie DocumentService o "opakowanie" mojego interfejsu w widok?
To masz na myśli?
NP: metoda DocumentService
ShowView(IDokument dok);

0

Dodatkowe pytanie.
Jak udostępniać moje "Dokumenty" na zewnątrz systemu?
Czy nadal buduje się systemy automatyzacji?
A może w net jest lepsza metoda?

0

DocumentService to nie fabryka. To serwis zapewniający logikę biznesową dla tych dokumentów jeśli jest ona na tyle prosta, ze nie wymaga jakiegoś DDD. Np metoda Create może użyć fabryki dokumentów do stworzenia dokumentu z parametrów przekazanych do metody Create serwisu. Metoda AddDocumentPosition serwisu sprawdza np. co trzeba i przelicza jakieś podsumowania itp.
Nie wiem co rozumiesz przez serwer automatyzacji bo mi się kojarzy z jakimś ActiveX z poprzedniego wieku.
Jeśli chcesz dostać dokument z "systemu" (obojętnie gdzie) to serwis Ci go da jako np. DTO, czyli obiekt który ma wszystkie potrzebne dane dokumentu, odczyta dane z bazy, zmapuje na DTO i zwróci DTO (czy tam ViewModel).

Twoje własne aplikacje mogą używać bezpośrednio tego serwisu a dla zewnętrznych możesz przygotować API w jakiejkolwiek postaci (dll, webapi), które dodatkowo zapewni Ci np uwierzytelnienie i większa kontrolę a to API będzie też używać tego serwisu.

Udostępnienie to zależy dla kogo (dla jakich aplikacji). Dla desktopowych w .NET wystarczy dll z jakimiś funkcjami do obsługi dokumentów (plus jakaś sesja, uwierzytelnienie itp - Comarch tak ma w XL), dla mobilnych i różnych innych to może być WebAPI (może być hostowane jako usługa Windows albo serwer WWW), która zwraca dokumenty formacie XML lub JSON.

0
jacek.placek napisał(a):

Nie wiem co rozumiesz przez serwer automatyzacji bo mi się kojarzy z jakimś ActiveX z poprzedniego wieku.

Tak. Więc tego już w ogóle się nie używa?

jacek.placek napisał(a):

Dla desktopowych w .NET wystarczy dll z jakimiś funkcjami do obsługi dokumentów

Jak w takim razie "załóżmy teoretycznie", udostępnić taki obiekt dla programu w Delphi? Pomijam WEB, SOAP ogólnie komunikację HTTP tutaj wiem.
Nazwa Technologi, gdzie można o tym poczytać?
Nie znam dokładnie mechanizmów .NET dlatego się dopytuje.

0

Jeśli app Delhpi jest poza .NET i nie rozumie .netowych assembly to może przez jakieś ogólne mechanizmy jak COM.
We właściwościach projektu dla DLL Assembly w .NET jest magiczna opcja register for COM Interop. Trzeba poczytać.

https://docs.microsoft.com/pl-pl/dotnet/framework/interop/exposing-dotnet-components-to-com

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