Jaki framework jest najtanszy? Opcje

[cepa]

Czesc,

projektuje pewien system ecommerce, poki co wysokopoziomowo, wymagania, mockupy, procesy biznesowe, generalnie co to ma robic. Na dniach bede musial zejsc poziom nizej na architekture, model danych i pojawia sie kwestia technologi i frameworka do implementacji.

Pytanie w jakiej technologi i w jakim frameworku to zaimplementowac?
Jakich narzedzi byscie uzyli do zbudowania systemu ecommerce tak aby mozna bylo oddelegowac prace zewnetrznej firmie lub zatrudnic programistow?

Zalozenia sa z grubsza takie:
- projekt wewnetrzny
- czas zycia systemu 2..3 lata
- wiele brandowanych instalacji
- frontend uzywany przez klientow i automatyczny backend
- brak backoffice (osobny projekt)
- integracje z zewnetrznymi systemami (platnosci, analityka)
- 1k...10k zarejestrowanych kientow
- relacyjna baza danych
- brak potrzeby skalowania (przy wiekszym ruchu i tak zostanie przepisany)

Nie jest to rocket science wiec po przekazaniu projektu do wdrozenia dobrze by bylo zeby mozna bylo go wykanac praca ludzi na poziomie junior/mid developer. Najlepiej ludzmi dostepnymi na Polskim rynku. Takze aby mozna bylo zmienic developerow w trakcie pracy nad systemem i pozniejszym utrzymaniem. Sklaniam sie ku PHP jako stosunkowo taniej i dostepnej technologii.

Dzieki z gory za odpowiedzi i sugestie.

Ten post edytował cepa 6.06.2016, 12:40:05

[Dejmien_85]

Pytanie w jakiej technologi i w jakim frameworku to zaimplementowac?

Nie jest to rocket science wiec po przekazaniu projektu do wdrozenia dobrze by bylo zeby mozna bylo go wykanac praca ludzi na poziomie junior/mid developer. Najlepiej ludzmi dostepnymi na Polskim rynku. Takze aby mozna bylo zmienic developerow w trakcie pracy nad systemem i pozniejszym utrzymaniem. Sklaniam sie ku PHP jako stosunkowo taniej i dostepnej technologii.

Może to zabrzmi okrutnie, ale technologia i framework nie mają nic do rzecz jeśli chodzi o sukces projektu. Możesz to zrobić w PHP, Node, a nawet i dałbyś radę w Cobalu. Fakt jest taki, że jak Ci to będą Juniorzy rozwijać, to wszystko spier...lą i ostatecznie będziesz miał spaghetti (code) i setki robali (bugów). ; )

Framework to detal - po latach tak naprawdę zrozumiałem, że framework to tylko kanał wejścia/wyjścia. Parsuje jedynie request, daje Ci routing, przy okazji dostajesz ORM-a i to tyle. Cała aplikację powinieneś napisać w Plain Objects, beż żadnego couplingu z frameworkiem, czy bazą danych. Clean Architecture się kłania.

Jedyne co widziałem przez ostatnie lata to pisanie, a później narzekanie, że kod stary, że framework stary, że przepisać by się przydało - takie stałe programistyczne pitolenie. Coupling to śmierć. Frameworki to zwykłe kanały I/O wypchane setkami niepotrzebnych pierdół, które tworzą niepotrzebny coupling Twojej logiki biznesowej z farmeworkiem.

Framework powinien być pluginem, niczym więcej - ale nie zrozumie tego ten, kto całe życie frameworki uważa za "szkielety". Tak, to szkielet - porażki.

Tyle z mojej strony, szerokości.

Ten post edytował Dejmien_85 14.06.2016, 22:13:01

[m44]

Może to zabrzmi okrutnie, ale technologia i framework nie mają nic do rzecz jeśli chodzi o sukces projektu. Możesz to zrobić w PHP, Node, a nawet i dałbyś radę w Cobalu. Fakt jest taki, że jak Ci to będą Juniorzy rozwijać, to wszystko spier...lą i ostatecznie będziesz miał spaghetti (code) i setki robali (bugów). ; )

Framework to detal - po latach tak naprawdę zrozumiałem, że framework to tylko kanał wejścia/wyjścia. Parsuje jedynie request, daje Ci routing, przy okazji dostajesz ORM-a i to tyle. Cała aplikację powinieneś napisać w Plain Objects, beż żadnego couplingu z frameworkiem, czy bazą danych. Clean Architecture się kłania.

Jedyne co widziałem przez ostatnie lata to pisanie, a później narzekanie, że kod stary, że framework stary, że przepisać by się przydało - takie stałe programistyczne pitolenie. Coupling to śmierć. Frameworki to zwykłe kanały I/O wypchane setkami niepotrzebnych pierdół, które tworzą niepotrzebny coupling Twojej logiki biznesowej z farmeworkiem.

Framework powinien być pluginem, niczym więcej - ale nie zrozumie tego ten, kto całe życie frameworki uważa za "szkielety". Tak, to szkielet - porażki.

Tyle z mojej strony, szerokości.

Ta jasne. Znam te plain object. Klika value objectów z interfejsami repozytoriów znajdującymi się w przestrzeni nazw o magicznej nazwie domain.
Żeby byla mowa o logice biznesowej, to projekt sam w sobie musi wynikać z biznesu, a tego w PHP-ie, który w większości służy do obsługi formularzy uświadczysz bardzo rzadko.