nauka angulara - wspolny moduł - dwie aplikacje, czy warunek

0

czesc!
niedawno przerobiłem kurs angulara,
chcę się go troszkę nauczyć więc zamierzam napisać swój mały projekt.
starając się go przemyśleć napotkałem już pierwszy problem ;]

w angularze (4) chcę zrobić sam front end,
cała logika będzie w c#, front end będzie wołał przez API.

w systemie będzie rezerwacja - tutaj jako przykład podam hotel

do systemu są dwa wejścia : klienci zewnętrzni (może zarezerwować sobie pobyt w hotelu), oraz pracownicy(mogący zarezerwować wizytę na prośbę klienta, bądź z innych powodów)
rzecz w tym, że pracownicy będą mieli trochę bardziej rozbudowaną wersję i więcej możliwości
jak to rozegrać - dwa osobne projekty - dwie osobne aplikacje, lecz w jednej z nich więcej modułów, oraz bardziej rozbudowany wspólny moduł? chyba niezbyt fajne rozwiązanie?

czy może ograniczać dostęp do modułów za pomocą angularowego routingu, a także ng-ifów?

proszę o pomoc, dopiero zaczynam z front endem :)

1

oraz bardziej rozbudowany wspólny moduł?

Co to znaczy bardziej rozbudowany wspólny moduł? Jak dzielisz apkę na moduły, to możesz (a nawet powinieneś) ją podzielić w taki sposób, żeby 1 moduł miał 1 odpowiedzialność.(zamiast moduł podstaw sobie "klasa", czy "funkcja" albo "serwis", jak zwał, tak zwał). Wtedy zbytnie rozbudowanie 1 modułu może spowodować powstanie tzw. god objectu (taki antywzorzec https://en.wikipedia.org/wiki/God_object)

czy może ograniczać dostęp do modułów

I tak będziesz musiał to walidować na backendzie.

0

Luke, trochę źle napisałem

moduł rejestracji będzie jeden.
jednakże pracownik będzie miał dodatkowo 2-3 funkcje (możliwości) więcej w tym module.

moduły raczej będą skąpe, staram się trzymać SOLID (i w tym przypadku single-resposibility, czy jak to się tam zwało ;])

0

Robisz jeden backend a dwa frontendy . Pierwszy frontend dla pracowników wysyła dodatkowe informacje w payloadzie a drugi który jest publiczny dla wszystkich takich informacji nie wysyła lub uderza pod inny endpoint

0

mimo tego że będzie bardzo dużo części wspólnej?

potem zmieniając coś w module rejestracji będę musiał dokonywać dwóch zmian naraz...
po stronie backendu być może załatwię obsługę tego dziedziczeniem...
czy po stronie frontu, a konkretniej angulara da się zrobić dziedziczenie w modułach :D?

1

Dziedziczenie w modułach @LukeJL WTF ???

1

Jeżeli coś wykombinujesz to z chęcią posłucham jak to zrobiłeś ale nie wróże sukcesu jeżeli jesteś na początku drogi z angularem .

1

czy po stronie frontu, a konkretniej angulara da się zrobić dziedziczenie w modułach :D

W ogóle jestem trochę w szoku, że w ogóle są moduły w Angularze 4 (myślałem, że angularowe moduły z jedynki straciły rację bytu wraz z modułami ES6... a przynajmniej powinni to jakoś inaczej nazwać, żeby się nie myliło).

Ale nie wiem, pisałem ogólnie o architekturze, technologia jest mało ważna. W ogóle powinieneś jak najmniej się uzależniać od Angulara (Reacta, Vue, niepotrzebne skreślić) i jak najwięcej kodu pisać w JavaScript (w sensie - jeśli potrzebujesz jakieś "rutyny", która coś przelicza albo jakiegoś "podprogramu", który odpala jakąś logikę, to lepiej będzie to napisać w czystym JS, w postaci zwykłej funkcji czy klasy ES6, a potem zimportować to z poziomu Angulara (Reacta, Vue, whatever), ew. "wstrzykiwać" to jakoś (piszę o abstrakcyjnej idei "wstrzykiwania", niezależnie jakie mechanizmy będą za tym stały).

Co do dziedziczenia, to nie wydaje mi się, żeby to było potrzebne - lepiej wydzielić po prostu trzeci moduł (taki jakby "common", "shared" itp.) i niech te moduły korzystają z tego wspólnego modułu (albo odwrotnie - odwrócić zależności i niech to ten wspólny moduł wywołuje osobne moduły).

Ale jak już chciałbyś coś podziedziczyć, to przecież możesz zrobić zwykłą klasę ES6:

class Foo extends SomeBaseClass {
}

mimo tego że będzie bardzo dużo części wspólnej?

potem zmieniając coś w module rejestracji będę musiał dokonywać dwóch zmian naraz...

nie rozumiem. Przecież właśnie po to są "moduły" (rozumiane jako abstrakcyjna idea), żeby móc trzymać gdzieś jeden moduł i używać go z zewnątrz. Właśnie po to są "moduły", żeby uniknąć konieczności dokonywania dwóch zmian naraz...

Myśl mniej w kategoriach "modułów" (jeśli masz zbyt duży bagaż związany z tym słowem), a może w kategoriach "bibliotek". Czyli nie robisz "modułu", a robisz pewną "bibliotekę", która będzie używana przez kilka projektów naraz.

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