Odpowiedzi:
Jeśli ramy są opiniowane, blokują lub poprowadzą cię do ich sposobu robienia rzeczy.
Na przykład: niektóre osoby uważają, że system szablonów nie powinien zapewniać dostępu do metod i funkcji zdefiniowanych przez użytkownika, ponieważ pozostawia system otwarty na zwracanie nieprzetworzonego HTML. Tak więc opiniotwórczy programista umożliwia dostęp tylko do struktur danych. Z założenia oprogramowanie ogranicza i zachęca projektanta do robienia rzeczy po swojemu.
Innym przykładem ( wziętym z linku sygnałów ) jest wiki . Projektanci wiki mieli wiele opinii. Uważali, że HTML jest zbyt skomplikowany, aby ludzie mogli go pisać, więc wymyślili, co według nich jest bardziej naturalnym sposobem aktualizacji treści. Pozbawili go również fantazyjnego wzornictwa, ponieważ uważali, że należy skupić się bardziej na treści niż na designie.
Apple ma mocne opinie, projektując swoje produkty.
Nieocenione projektowanie oprogramowania przypomina bardziej PERL / PHP. Pozwala programistom i ufa programistom w podejmowaniu właściwych decyzji i daje większą kontrolę w ich rękach.
Umieściłbym także Microsoft w nieocenionej kolumnie. Dobrym przykładem Microsoft ramach która jest un-opininated: .NET. Otwierając CLR i specyfikacje, otworzył go na wszelkiego rodzaju języki i style implementacji.
Specjalistyczne oprogramowanie oznacza, że istnieje zasadniczo jeden sposób ( właściwy sposób ™) na robienie rzeczy, a próba zrobienia tego inaczej będzie trudna i frustrująca. Z drugiej strony, robienie rzeczy we właściwy sposób ™ może bardzo ułatwić programowanie, ponieważ liczba decyzji, które musisz podjąć, jest ograniczona, a zdolność projektantów oprogramowania do skoncentrowania się na tworzeniu oprogramowania jest zwiększona. Wymyślone oprogramowanie może być świetne w użyciu, jeśli zostanie wykonane dobrze, jeśli problem ładnie odwzorowuje się na rozwiązaniu. Rozwiązaniem tych części problemu, które nie są odwzorowane na dostarczone narzędzia, może być prawdziwy problem. Przykładem może być Ruby on Rails.
Z drugiej strony oprogramowanie bez opinii pozostawia dużą elastyczność użytkownikowi (deweloperowi). Nie zakazuje jednej metody rozwiązania problemu, ale zapewnia elastyczne narzędzia, których można użyć do rozwiązania problemu na wiele sposobów. Wadą tego może być to, że ponieważ narzędzia są tak elastyczne, opracowanie jakiegokolwiek rozwiązania może być stosunkowo trudne. Znacznie więcej rozwiązań może wymagać ręcznego kodowania przez użytkownika (programistę), ponieważ środowisko nie zapewnia wystarczającej pomocy. Musisz także pomyśleć znacznie więcej o tym, jak zapewnić rozwiązanie, a mierni programiści mogą skończyć na gorszych rozwiązaniach, niż gdyby kupili jakieś opiniotwórcze oprogramowanie. PERL jest prawdopodobnie klasycznym przykładem nieocenionego oprogramowania.
Moim ideałem są nieocenione ramy, ale oparte na silnych konwencjach. Umieściłbym ASP.NET MVC w tej kategorii. W rzeczywistości całe oprogramowanie jest do pewnego stopnia opiniowane (choć może nie PERL). MVC ma silne konwencje w wyborze modelu, ale oferuje wiele różnych sposobów rozwiązywania problemów w ramach tych konwencji. Niektóre z tych sposobów mogą nawet popsuć model. Jednak prawidłowe stosowanie, zgodnie z konwencjami rozwijającymi się w takich ramach, może być prawdziwą radością.
Zasadniczo jest to oprogramowanie, które działa tak, jak sądzą jego autorzy, zamiast próbować zadowolić wszystkich. Oznacza to, że wielu ludziom się to nie spodoba, ale ci, którzy to zrobią, pokochają to.
Rails to prawdopodobnie kanoniczny przykład opiniotwórczego frameworka: robisz wszystko po swojemu i wszystko jest płynne. Jeśli tego nie zrobisz, czeka cię ból. Ale to w porządku - jeśli nie chcesz robić rzeczy po swojemu, nie chcesz używać Railsów.
Dla zachowania równowagi przedstawię (raczej uparty) opis, który jest bardziej korzystny dla takiego podejścia (w przeciwieństwie do niektórych innych odpowiedzi).
Opiniowane ramy zapewniają „złotą ścieżkę”, która ma być najlepszą praktyką dla większości ludzi i większości scenariuszy (w oczach autorów).
Nie musi to jednak oznaczać blokady. Oznacza to, że może wymagać dodatkowego wysiłku, aby robić różne rzeczy.
Mniej opiniotwórcze ramy zapewniają wiele różnych opcji i wybór należy do Ciebie.
Wypracowane ramy zwykle usuwają ciężar programisty, aby wymyślić koło lub przemyśleć ten sam problem od nowa i tym samym pomóc skupić się na rzeczywistym problemie.
W świecie open source można znaleźć wiele opiniotwórczych, ale konkurencyjnych platform, więc nadal masz wybór. Musisz tylko wybrać własną złotą ścieżkę.
Ocenione oprogramowanie jest zbudowane i zaprojektowane w taki sposób, że ułatwia robienie rzeczy w określony sposób. Sprzyja niektórym wzorom projektowym bardziej niż innym. W procesie tym trudno jest odejść od stylu tworzenia oprogramowania, dla którego został opracowany. Innym sposobem na wyrażenie tego jest to, że preferuje „Konwencję nad konfiguracją”. tzn. opcje konfiguracji są bardzo ograniczone, ponieważ oprogramowanie obejmuje wiele aspektów konfiguracji. Oprogramowanie z opiniami jest zwykle szybsze do opanowania po zrozumieniu założeń.
Z drugiej strony, niepopionowane oprogramowanie nie ma wielu założeń. W rezultacie, nieopinowane ramy programistyczne / oprogramowania często mają wiele opcji konfiguracyjnych. Deweloper zazwyczaj musi podejmować wiele decyzji dotyczących różnych aspektów oprogramowania. Często opracowywane są różne narzędzia, aby ułatwić radzenie sobie z tymi ogromnymi opcjami. np. Visual Studio .NET dla .NET, Eclipse IDE dla Java itp. Oprogramowanie nieopinowane zwykle zajmuje więcej czasu niż oprogramowanie opiniotwórcze.
tl; dr :
Wiele osób odnosi się do ASP.NET MVC jako „nieopinowanego” frameworka, a ja po prostu chciałem się nad tym zastanowić.
To prawda, że ASP.NET MVC nie wymaga zbyt wiele; możesz użyć dowolnego rozwiązania trwałości, które ci się podoba, czy to Linq-to-SQL, ADO.NET Entities, NHibernate itp.
Z drugiej strony framework MVC ma tendencję do faworyzowania „konwencji nad konfiguracją”, cytując Phila Haacka, który mocno sugeruje stosowanie się do wcześniej zdefiniowanego wzorca lokalizacji kontrolerów, widoków, modeli i innego kodu. Chociaż możesz zmienić to zachowanie, łatwiej jest pływać z prądem, a dla większości ludzi nie ma problemu.
Również w środowisku ASP.NET MVC znajduje się wiele opiniotwórczych osób, które według mnie prowadzą do stronniczych poradników, które nalegają na omówienie, np. Testowanie jednostkowe i wstrzykiwanie zależności; Jestem za dobrym testowaniem i rozwiązywaniem problemów, ale zdaję sobie sprawę, że takie tematy są trochę wrzucane do gardła, często przed omówieniem bardziej przydatnych podstaw.
Tu znowu muszę przyznać, że w tych obszarach sama platforma jest całkowicie otwarta na przyjęcie dowolnego rozwiązania do testowania jednostkowego, a także dowolnego wstrzykiwania zależności i próbnych ram, których chcesz użyć, więc sądzę, że to kolejny przykład elastyczność, nawet w ramach „biblijnego uderzania” testów jednostkowych itp., które wydają się mieć miejsce.
Jest to liczba konwencji wdrożonych w ramach i liczba podjętych decyzji.
Jeśli na przykład istnieje 5 (lub więcej) różnych sposobów przesyłania danych formularza do działania kontrolera (co ma miejsce w ASP.NET MVC), struktura wydaje się dość „bezdyskusyjna” - decyzja jest podjęta Tobie!
Jeśli jednak środowisko umożliwia (bezpośrednio wyłączając inne sposoby lub silnie je zachęcając) tylko jeden sposób robienia tego (co ma miejsce w przypadku Fubu MVC), można powiedzieć, że środowisko zostało podjęte przez środowisko , w ten sposób opiniując ramy.
Przykładem, który obecnie bardzo dużo zobaczysz, jest środowisko ASP.NET MVC. Jest niesamowicie rozszerzalny, ale pod pewnymi względami jest to wadą, nie ma w nim mięsa. Chcesz uzyskać dostęp do danych? Musisz to napisać sam. Chcesz trochę AJAX? Tak samo.
Ponieważ jednak jest on w znacznym stopniu rozszerzalny, jeśli go wykorzystasz, możesz przekształcić go w oparte na opiniach ramy. To właśnie robią MVCContrib , dają ci określone metody robienia rzeczy, co oznacza, że musisz napisać mniej kodu.
Oznacza to, że jeśli chcesz oderwać się od opinii, często musisz wykonać więcej pracy niż w przypadku wersji waniliowej. Jest to jednak scenariusz 80/20. Jeśli prawidłowo wybierzesz opiniotwórcze ramy, będziesz chciał oderwać się od opinii tylko przez 20% czasu, a przez pozostałe 80% będziesz bardzo produktywny.