To pytanie koncentruje się na wyodrębnieniu zalet i wad korzystania ze struktur opartych na sieci Web : takich jak Cake PHP, Zend, jQuery, ASP.NET). To pytanie jest całkowicie niezależne od języka . Zacznę od pojęcia „Stanie na ramionach gigantów ”.
Zalety:
- Wspiera programistów - dzięki funkcjom, które wcześniej zajęłyby setki wierszy kodu i kompresji ich w jednym prostym wywołaniu funkcji, umożliwia programistom integrację bardziej złożonych funkcji w ich witrynach internetowych.
- Pozwól na szybsze tworzenie aplikacji - jest to bardzo istotne dla osób, które potrzebują stron internetowych utworzonych w bardzo małym oknie (czy ktoś ma tego przykłady?)
- Niższe koszty - umożliwia programistom przeniesienie oszczędności na klienta, generuje zupełnie nową grupę klientów, którzy chcieli mieć stronę internetową, ale wcześniej nie mogli sobie pozwolić na wyższe koszty rozwoju.
Niedogodności:
- Utracone zrozumienie - opierając się na funkcjach frameworka, deweloperowi grozi utrata zrozumienia tego, jak rzeczy działają (pod maską).
- Klif konfiguracji - jeśli pójdziesz dalej niż konfiguracja swojego frameworka, Twoja produktywność spada, może być trudno wdrożyć funkcje poza konfiguracją frameworka.
- Ścieżki dla programistów - ty (programista) musisz robić rzeczy w sposób, w jaki programista chce, abyś to robił.
Zastanawiam się, co ludzie sądzą o moich opiniach i czy ktoś się z nimi nie zgadza? Również jeśli ludzie mają dodatkowe punkty, byłbym wdzięczny.
źródło
Con: Ewentualny możliwy spadek wsparcia / utrata popularności
Pro: Kod dla biznesu
źródło
Zalety
Niedogodności
Opowiadam się za stosowaniem ram do wszystkich projektów oprócz najprostszych. Jeśli chcesz dodać formularz kontaktowy do istniejącej witryny HTML, możesz użyć jednego pliku PHP zamiast przejść do frameworka.
źródło
Przypomina mi się kilka rzeczy ...
Zalety
Niedogodności
źródło
Wszystko zależy od używanego frameworka.
Jeśli korzystasz z ASP.NET, masz wadę: w najlepszym razie jest to nieszczelna abstrakcja , aw najgorszym przypadku robienie rzeczy, które są trywialne w innych ramach, nie ukrywają faktu, że jesteś praca w sieci.
ASP.NET MVC stara się rozwiązać ten problem i robi to dobrze.
Ramy istnieją, abyśmy mogli spędzać więcej czasu na wykonywaniu pracy, a mniej na budowaniu rusztowań. Pod tym względem nie widzę żadnych wad, chyba że naprawdę chcesz spędzać czas na budowaniu rusztowań.
źródło
Chciałbym dodać kilka punktów.
Nadal uważam, że włożenie nieco więcej wysiłku w ocenę ram, ocenę licencji, utrzymywanie czystej listy ram dla każdego zastosowania i inteligentną strategię wersjonowania są tego warte, jeśli weźmiemy pod uwagę zalety.
Zalety:
źródło
Mówię z własnego doświadczenia w ciągu ostatnich 13 lat. W mojej firmie zastosowaliśmy rozpórki, po krótkim zakręcie było świetnie. W mojej następnej zastosowaliśmy architekturę, która była w większości nieprzezroczysta, nieco rozpięta, ale wyhodowana, mogliśmy ją rozszerzyć, ale podstawowy kod to tylko słoiki. I tak dalej. w ciągu ostatnich 3 lat pracowałem w małej firmie (liczba deweloperów <30) i to były wszystkie nasze jsp, serwlety i ejbs. Patrząc na wielu naszych klientów i powtarzanie plików JSP, w 2012 roku stworzyliśmy filtr j2ee, który naśladował 20% struts2. Dlaczego nie użyć stuts 2? Szkoda, że nie mieliśmy, ale: nie mogliśmy tego przekazać naszemu głównemu architektowi; za mało doświadczenia lub czasu.
Więc mieliśmy przechwytujące niektóre typowe pliki JSP, których używał nasz mini framework. Teraz, kiedy miałem czas przejść książkę „Struts 2”, widzę, że tak bardzo za nami tęskniliśmy!
Używamy świetnych algorytmów, pamięci podręcznych i interfejsu użytkownika, ale straciliśmy wiele godzin i obciążono dużą ilością kodu, który planujemy wycofać na 3 lata.
źródło