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.

Oto sedno: wdrożenie funkcji poza konfiguracją frameworków może być trudne.

Przejdźmy przez to założenie przez założenie.

Utracone zrozumienie - polegając na funkcjach frameworka, programista może stracić zrozumienie tego, jak działa (pod maską).

Fałszywy. Nigdy nie stracisz zrozumienia, jak to działa. Ramy nie są magiczne. To po prostu przydatny kod, którego nie musisz pisać sam.

Wierzcie lub nie, popełniacie błędy przy użyciu frameworka. Będziesz musiał debugować aż do najniższych poziomów HTTP, aby zrozumieć, co zrobiłeś źle.

Nigdy nie stracisz z oczu tego, co dzieje się pod maską. Chyba że twoje środowisko jest tak epickie i idealne, że nigdy nie będziesz mieć problemu.

Klif konfiguracji - jeśli pójdziesz dalej niż konfiguracja swojego frameworka, Twoja produktywność spada, może być trudno wdrożyć funkcje poza konfiguracją frameworka.

To bezcenne ma sens.

Pierwszy. Budowanie bez frameworka może sprawić, że banalne zadanie stanie się dużym zadaniem programistycznym, które obejmuje testowanie jednostki, debugowanie, diagnostykę, kontrolę konfiguracji i całą resztę pracy bez wartości, odkrywając na nowo to, co znajduje się w frameworku. Jaka jest ta „produktywność”?

Druga. Wdrażanie rzeczy poza frameworkiem jest zawsze dużo pracy, ponieważ - hm - wdrażanie czegokolwiek poza frameworkiem jest zawsze dużo pracy. Nie ma to nic wspólnego z czasem poświęconym na naukę i konfigurowanie frameworka. Wdrażanie czegokolwiek poza ramami jest z natury trudne.

Ścieżki dla programistów - ty (programista) musisz robić rzeczy w sposób, w jaki twórca [frameworku] chce, abyś to robił.

Poprawny. I to często jest dobra rzecz. Robienie rzeczy w sposób konsekwentny jest cenniejsze niż robienie ich według własnych preferencji. Może wymagać „nauki” i „zrozumienia”, ale mają one wartość.

Kwestie bezpieczeństwa - udostępnienie ludziom tych narzędzi do szybkiego tworzenia profesjonalnie wyglądających stron internetowych stanowi potencjalne ryzyko, ludzie mogą szybko tworzyć profesjonalnie wyglądające strony internetowe dla nieuczciwych firm.

Co? To nie ma nic wspólnego z frameworkiem. Oszustwo to oszustwo, niezależnie od użytych narzędzi.

Con: Ewentualny możliwy spadek wsparcia / utrata popularności

• Jeśli istnieją dwa frameworki, które robią to samo, a twój nie wygrywa, istnieje szansa, że ​​projekt umrze. W tej sytuacji możesz samodzielnie utrzymywać framework (open source), przepisać aplikację lub kontynuować bez aktualizacji (zamknięte źródło).
• W zależności od frameworka może być konieczne uaktualnienie aplikacji zgodnie z harmonogramem jego wydania. Pozostawanie zbyt daleko w tyle może uniemożliwić uzyskanie wsparcia. Bez ram możesz pracować zgodnie z harmonogramem. (Zależy to od tego, czy potrzebujesz wsparcia, czy nie).

Pro: Kod dla biznesu

• Szkielety pozwalają ci nie martwić się o cholerną pracę i skupiają się na kodzie, który bezpośrednio wnosi wartość dla biznesu.
• Czasami aktualizacje frameworku, które (po prostu działają) umożliwiają dostarczanie użytkownikom nowych funkcji praktycznie „za darmo”. Zwłaszcza w ramach dostarczanych z niestandardowymi kontrolkami (jak siatka, że ​​nowa wersja może oferować pewien rodzaj wyszukiwania / filtrowania).

Zalety

• Szybszy czas programowania
• Mniej błędów
• Szybszy wspólny rozwój
• Obsługa bibliotek
• Łatwa interakcja DB

Niedogodności

• „Zapakowane” w ramy
• Często nieelastyczny, gdy chce się rozszerzyć lub zmodyfikować podstawowe zachowanie
• „Błędy zguby” - błędy, które powstają z rdzenia lub podstawowej architektury bez dobrego prześledzenia źródła. Doskonałym przykładem są błędy wiosenne podczas korzystania z Grails.

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.

Przypomina mi się kilka rzeczy ...

Zalety

• Ponowne użycie kodu - używając frameworka, ponownie wykorzystujesz sprawdzony i prawdziwy kod.
• Szybki rozwój / prototypowanie.
• (często) zintegrowane sprawdzanie poprawności danych wejściowych, które można uznać za bezpieczne (pod warunkiem, że programista używa go poprawnie)

Niedogodności

• Utrata wsparcia. Przychodzi na myśl Symfony 1.4. Wyobrażam sobie, że Symfony będzie obsługiwać 1.4 przez dłuższy czas, ale wiedząc, że 2.0 nie jest kompatybilny wstecz, 1.4 wydaje się być ślepym wsparciem w nadchodzących latach.
• Nad głową; Korzystając z frameworka, uruchomisz tysiące linii, które mogą nie mieć zastosowania do konkretnej aplikacji, ale dotyczą innych. Niektórzy uważają to za rozsądny kompromis, a niektórzy decydują się napisać swój kod od podstaw dla wydajności.
• Używanie niewłaściwych ram dla konkretnych potrzeb. Nie wszystkie frameworki są tworzone jednakowo.

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ń.

Chciałbym dodać kilka punktów.

• Jednym z największych problemów z frameworkami, które znalazłem, jest to, że ludzie przestają myśleć. Chcą tylko użyć frameworka, ponieważ jest fajny lub ponieważ zawsze używają frameworka. Nie przestają myśleć, czy użycie jest uzasadnione.
• Licencjonowanie, ludzie po prostu wydają się korzystać z frameworków, nie patrząc na licencje. Może to mieć implikacje, że nie są świadomi. Lub zastanów się, co się stanie, gdy zmieni się licencja.
• Korzystanie z wielu tego samego rodzaju ram. Czasami mogą to być różne frameworki, które w rzeczywistości robią prawie to samo. Jako firma dokonujesz świadomych wyborów i nie masz innych ram dla każdego projektu.
• Nadążanie za nowymi wersjami może być wyzwaniem

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:

• kiedy konsekwentnie używasz ram, czas nauki dla projektów zmniejsza się dla osób, które już pracowały nad twoimi projektami.
• twój własny szybszy rozwój
• twoi programiści

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.