Dlaczego miałbym używać Scala / Lift over Java / Spring? [Zamknięte]

Wiem, że to pytanie jest trochę otwarte, ale patrzyłem na Scala / Lift jako alternatywę dla Java / Spring i zastanawiam się, jakie są rzeczywiste zalety, jakie ma nad nim Scala / Lift. Z mojego punktu widzenia i doświadczenia, Java Annotations i Spring naprawdę minimalizują ilość kodowania, które musisz wykonać dla aplikacji. Czy Scala / Lift to poprawia?

Załóżmy, że czujemy się równie dobrze w Scali i Javie i zignorujmy (ogromne) różnice językowe, z wyjątkiem tych, które dotyczą Spring lub Lift.

Wiosna i Wyciąg są niemal diametralnie przeciwstawne pod względem dojrzałości i celów.

• Wiosna jest o około pięć lat starsza niż Lift
• Lift jest monolityczny i jest skierowany tylko do sieci; Spring jest modułowy i jest przeznaczony zarówno dla aplikacji internetowych, jak i „zwykłych”
• Spring obsługuje wiele funkcji Java EE; Winda ignoruje te rzeczy

Jednym zdaniem Spring jest ciężki, a Lift jest lekki. Mając wystarczającą determinację i zasoby, możesz to postawić na głowie, ale będziesz potrzebować dużo obu.

Oto konkretne różnice, które utknęły mi w pamięci po pracy z obydwoma frameworkami. To nie jest wyczerpująca lista, której i tak nie mogę skompilować. To, co wydało mi się najbardziej interesujące ...

1. Zobacz filozofię

   Podnieś zachęca do umieszczania materiału widoku w metodach fragmentów / akcji. W szczególności kod fragmentu zostanie pokropiony programowo wygenerowanymi elementami formularza, <div>s, <p>s itp.

   Jest to potężne i przydatne, zwłaszcza że Scala ma wbudowany tryb XML na poziomie języka. W metodach Scala można pisać XML inline, w tym zmienne wiązania w nawiasach klamrowych. Może to być wspaniałe w przypadku bardzo prostych usług XML lub makiet usług - możesz wykonać zestaw akcji odpowiedzi HTTP w jednym wspaniałym, zwięzłym pliku, bez szablonów i wielu towarzyszących mu konfiguracji. Wadą jest złożoność. W zależności od tego, jak daleko się posuwasz, istnieje albo rozmyta separacja obaw między widokiem a logiką, albo brak oddzielenia.

   W przeciwieństwie do tego, regularne używanie Springa w aplikacjach internetowych wymusza silne oddzielenie widoku od wszystkiego innego. Myślę, że Spring obsługuje kilka silników szablonów, ale ja używałem JSP tylko w poważnych sytuacjach. Stworzenie projektu "rozmytego MVC" inspirowanego Lift'em z JSP byłoby szaleństwem. To dobra rzecz w przypadku większych projektów, gdzie czas na przeczytanie i zrozumienie może być przytłaczający.

2. Wybory mapowania obiektowo-relacyjnego

   Wbudowany ORM windy to „Mapper”. Nadchodzi alternatywa o nazwie „Record”, ale myślę, że nadal jest uważana za pre-alpha. Książka LiftWeb zawiera sekcje dotyczące używania zarówno programu Mapper, jak i JPA.

   Funkcja CRUDify Lift, choć fajna, działa tylko z Mapper (a nie JPA).

   Oczywiście Spring obsługuje całą gamę standardowych i / lub dojrzałych technologii baz danych . Działającym słowem jest „podpory”. Teoretycznie możesz użyć dowolnego Java ORM z Lift, ponieważ możesz wywołać dowolny kod Java ze Scali. Ale Lift naprawdę obsługuje tylko Mappera i (w znacznie mniejszym stopniu) JPA. Ponadto praca z nietrywialnym kodem Java w Scali nie jest obecnie tak płynna, jak by się wydawało; Korzystając z Java ORM, prawdopodobnie będziesz używać wszędzie zarówno kolekcji Java, jak i Scala, lub konwertować wszystkie kolekcje do i z komponentów Java.

3. Konfiguracja

   Aplikacje podnoszące są konfigurowane prawie całkowicie za pomocą metody klasy „rozruchowej” obejmującej całą aplikację. Innymi słowy, konfiguracja odbywa się za pomocą kodu Scala. Jest to idealne rozwiązanie dla projektów z krótkimi konfiguracjami, a osoba dokonująca konfiguracji może swobodnie edytować Scala.

   Wiosna jest dość elastyczna pod względem konfiguracji. Wiele opcji konfiguracyjnych można uruchomić za pomocą konfiguracji XML lub adnotacji.

4. Dokumentacja

   Dokumentacja windy jest młoda. Dokumenty Springa są dość dojrzałe. Nie ma konkursu.

   Ponieważ dokumentacja Springa jest już dobrze zorganizowana i łatwa do znalezienia, przejrzę dokumenty, które znalazłem dla Lift. Istnieją zasadniczo 4 źródła dokumentacji Lift: LiftWeb Book , API Docs , LiftWeb's Google group i „ Getting Started ”. Jest też niezły zestaw przykładów kodu, ale nie nazwałbym ich „dokumentacją” per se.

   Dokumentacja API jest niekompletna. Książka LiftWeb została opublikowana na drzewach, ale jest również bezpłatnie dostępna online. Jest naprawdę pożyteczna, choć czasem irytował mnie jej zdecydowanie dydaktyczny styl. Jest trochę za długi na samouczek i krótki na kontrakt. Wiosna ma odpowiednią instrukcję, której brakuje Lift.

   Ale Lift ma niezły zestaw przykładów. Jeśli czujesz się komfortowo czytając kod windy i przykładowy kod (i znasz już dobrze Scalę), możesz rozwiązać problem w dość krótkim czasie.

Oba frameworki są atrakcyjne. Istnieje szeroka gama aplikacji, w których możesz wybrać jedną z nich i dobrze sobie radzić.

Muszę powiedzieć, że zdecydowanie nie zgadzam się z odpowiedzią Dana LaRocque.

Winda nie jest monolityczna. Składa się z dyskretnych elementów. Nie ignoruje elementów J / EE, obsługuje takie elementy jak JNDI, JTA, JPA itp. Fakt, że nie jesteś zmuszony do korzystania z tych elementów J / EE jest mocnym wskazaniem na modułową konstrukcję Lift.

• Filozofia Lift to „niech zdecyduje deweloper”. Lift oferuje mechanizm tworzenia szablonów, który nie dopuszcza żadnego kodu logicznego w widoku, mechanizm widoku oparty na wykonywaniu kodu Scala i literałów XML Scali oraz mechanizm widoku oparty na Scalate . Jeśli wybierzesz mechanizm tworzenia szablonów XML, wybierzesz, ile, jeśli w ogóle, narzut należy do logiki biznesowej. Separacja widoku Lift jest silniejsza niż cokolwiek, co ma do zaoferowania Spring, ponieważ nie można wyrazić żadnej logiki biznesowej w szablonach XML firmy Lift.
• Filozofia Lift's Object ↔ Trwałość to „niech zdecyduje deweloper”. Winda ma Mapper, który jest mapowaniem obiektów w stylu ActiveRecord. Wykonuje pracę w przypadku małych projektów. Podnieś wspornik JPA. Lift ma abstrakcję Record, która obsługuje przenoszenie obiektów do i z relacyjnych baz danych, do i z magazynów NoSQL (Lift obejmuje natywną obsługę CouchDB i MongoDB, ale warstwy adaptera to kilkaset linii kodu, więc jeśli chcesz, aby Cassandra lub coś innego, uzyskanie tego nie jest dużo pracy). Zasadniczo, Lift the Web Framework nie ma zależności od tego, jak obiekty są materializowane w sesji. Ponadto cykle sesji i żądań są otwarte tak, że wstawianie haków transakcji do cyklu żądanie / odpowiedź jest proste.
• Filozofia Lift to „zespół obsługujący serwer musi znać jeden język, a nie wiele języków”. Oznacza to, że konfiguracja odbywa się za pośrednictwem Scali. Oznacza to, że nie musieliśmy implementować 40% konstrukcji języka Java w składni XML, aby stworzyć elastyczne opcje konfiguracyjne. Oznacza to, że składnia kompilatora i typ sprawdzają dane konfiguracyjne, aby nie uzyskać żadnych dziwnych analiz XML lub nieprawidłowych danych w czasie wykonywania. Oznacza to, że nie musisz mieć środowisk IDE, które rozumieją szczegóły adnotacji, których używasz, na podstawie używanej biblioteki.
• Tak, dokumentacja Lift nie jest jego mocną stroną.

Mając powyższe na uwadze, pozwólcie, że opowiem o filozofii projektowania firmy Lift.

Napisałem Manifest Web Framework zanim zacząłem pisać Lift. W dużym stopniu i w większym stopniu niż w przypadku innych znanych mi platform internetowych, Lift spełnia te cele.

Lift w swoim rdzeniu stara się wyodrębnić cykl żądanie / odpowiedź HTTP, zamiast umieszczać opakowania obiektów wokół żądania HTTP. Na poziomie praktycznym oznacza to, że większość działań, które użytkownik może wykonać (przesyłanie elementów formularza, wykonywanie Ajax itp.) Jest reprezentowana przez identyfikator GUID w przeglądarce i funkcję na serwerze. Gdy identyfikator GUID jest prezentowany jako część żądania HTTP, funkcja jest stosowana (wywoływana) z podanymi parametrami. Ponieważ identyfikatory GUID są trudne do przewidzenia i zależne od sesji, ataki typu Replay i wiele ataków polegających na manipulowaniu parametrami są znacznie trudniejsze w przypadku Lift niż większość innych platform internetowych, w tym Spring. Oznacza to również, że programiści są bardziej produktywni, ponieważ koncentrują się na działaniach użytkownika i logice biznesowej związanej z działaniami użytkownika, a nie na pakowaniu i rozpakowywaniu żądania HTTP.

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

To takie proste. Ponieważ friendRequest znajduje się w zakresie podczas tworzenia funkcji, funkcja zamyka się w zakresie ... nie ma potrzeby ujawniania klucza podstawowego żądania znajomego ani robić nic innego ... po prostu zdefiniuj tekst przycisku (to może być zlokalizowane lub może być wyciągnięte z szablonu XHTML lub może zostać pobrane ze zlokalizowanego szablonu) oraz funkcję do wykonania po naciśnięciu przycisku. Lift zajmuje się przypisywaniem identyfikatora GUID, konfigurowaniem wywołania Ajax (przez jQuery lub YUI, i tak, możesz dodać własną ulubioną bibliotekę JavaScript), wykonywaniem automatycznych ponownych prób z cofnięciami, unikaniem utraty połączenia przez kolejkowanie żądań Ajax itp.

Tak więc jedną dużą różnicą między Lift a Spring jest to, że filozofia Lift dotycząca GUID związana z funkcją ma podwójną korzyść: znacznie lepsze zabezpieczenia i znacznie lepszą produktywność programistów. Powiązanie GUID -> Function okazało się bardzo trwałe ... ta sama konstrukcja działa dla normalnych formularzy, Ajax, komety, wielostronicowych kreatorów itp.

Następnym głównym elementem Lift jest utrzymanie abstrakcji wysokiego poziomu tak długo, jak to możliwe. Po stronie generowania strony oznacza to budowanie strony jako elementów XHTML i utrzymywanie strony jako XHTML do momentu tuż przed przesłaniem odpowiedzi. Korzyści to odporność na błędy cross-site scripting, możliwość przenoszenia tagów CSS do nagłówka i skryptów na dół strony po skomponowaniu strony oraz możliwość przepisania strony w oparciu o docelową przeglądarkę. Po stronie wejściowej adresy URL można ponownie zapisać w celu wyodrębnienia parametrów (zarówno zapytań, jak i parametrów ścieżki) w sposób bezpieczny dla typu, dane sprawdzone pod kątem bezpieczeństwa na wysokim poziomie są dostępne do przetwarzania na bardzo wczesnym etapie cyklu żądania. Na przykład, oto jak zdefiniować obsługę żądania REST:

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

Korzystając z wbudowanego dopasowania wzorców Scali, dopasowujemy przychodzące żądanie, wyodrębniamy trzecią część ścieżki i pobieramy użytkownika, który odpowiada tej wartości, a nawet stosujemy kontrole dostępu (czy bieżąca sesja lub żądanie ma uprawnienia dostępu do podanej Rekord użytkownika). Tak więc, zanim wystąpienie użytkownika trafi w logikę aplikacji, jest sprawdzane.

Dzięki tym dwóm podstawowym elementom Lift ma ogromną przewagę pod względem bezpieczeństwa. Aby dać ci wyobrażenie o wielkości zabezpieczeń Lift, które nie przeszkadzają funkcjom, Rasmus Lerdorg, który wykonał zabezpieczenia dla Yahoo! miał to do powiedzenia na temat FourSquare (jedna z witryn podrzędnych z plakatem Lift):

Cztery gwiazdki na @foursquare - Pierwsza strona od jakiegoś czasu dobrze się przyjrzałem, która nie miała ani jednego problemu z bezpieczeństwem (który mogłem znaleźć) - http://twitter.com/rasmus/status/5929904263

W tym czasie FourSquare miał jednego inżyniera pracującego nad kodem (nie żeby @harryh nie był super-geniuszem), a jego głównym celem było ponowne napisanie wersji FourSquare w PHP przy jednoczesnym podwojeniu ruchu w tygodniu.

Ostatnią częścią bezpieczeństwa Lift jest SiteMap. To ujednolicona kontrola dostępu, nawigacja po witrynie i system menu. Deweloper definiuje reguły kontroli dostępu dla każdej strony przy użyciu kodu Scala (np. If(User.loggedIn _)Lub If(User.superUser _)), a te reguły kontroli dostępu są stosowane przed rozpoczęciem renderowania strony. To jest bardzo podobne do Spring Security, z tym wyjątkiem, że jest zapieczętowane od początku projektu, a reguły kontroli dostępu są ujednolicone z resztą aplikacji, więc nie musisz mieć procesu aktualizacji reguł bezpieczeństwa w XML, gdy adresy URL zmiana lub metody obliczania zmiany kontroli dostępu.

Podsumowując do tej pory, filozofia projektowania Lift zapewnia korzyści wynikające z kontroli dostępu, odporności na 10 największych luk w zabezpieczeniach OWASP, znacznie lepszą obsługę Ajax i znacznie wyższą produktywność programistów niż Spring.

Ale Lift zapewnia również najlepszą obsługę Comet spośród wszystkich dostępnych frameworków internetowych. Właśnie dlatego Novell wybrał Lift do zasilania swojego produktu Pulse i oto, co Novell ma do powiedzenia na temat Lift:

Lift to rodzaj frameworka internetowego, który umożliwia programistom skoncentrowanie się na szerszej perspektywie. Silne, ekspresyjne pisanie i funkcje wyższego poziomu, takie jak wbudowana obsługa Comet, pozwalają skupić się na innowacjach zamiast na hydraulice. Tworzenie bogatej aplikacji internetowej działającej w czasie rzeczywistym, takiej jak Novell Pulse, wymaga struktury z mocą Lift pod osłonami.

Tak więc Lift to nie tylko kolejny framework MVC dla mnie. Jest to framework, który ma za sobą kilka podstawowych zasad projektowych, które bardzo dobrze dojrzały. Jest to struktura, która zapewnia podwójne korzyści w postaci bezpieczeństwa i produktywności programistów. Lift to framework, który jest zbudowany w warstwach i daje programiście właściwe wybory w oparciu o ich potrzeby ... wybory dotyczące generowania widoku, wybory dotyczące trwałości itp.

Scala i Lift zapewniają programistom znacznie lepsze wrażenia niż połączenie XML, adnotacji i innych idiomów tworzących Spring.

Polecam zapoznać się z frameworkiem do zabawy, ma kilka bardzo ciekawych pomysłów i wspiera rozwój w Javie i Scali

Dla żartu. I ze względu na naukę nowych podejść do programowania.

Bardzo chciałem użyć Lift w niedawnym projekcie internetowym, nie będąc wielkim fanem Spring MVC. Nie korzystałem z najnowszych wersji, ale wcześniejsze wersje Spring MVC sprawiły, że przeskoczyłeś przez wiele kółek, aby uruchomić aplikację internetową. Byłem prawie sprzedany na Lift, dopóki nie zobaczyłem, że Lift może być bardzo zależny od sesji i wymagałby `` lepkich sesji '', aby działać poprawnie. Fragment z http://exploring.liftweb.net/master/index-9.html#sec:Session-Management

Dopóki nie pojawi się standardowa technologia replikacji sesji, nadal można klastrować swoją aplikację przy użyciu „trwałej sesji”. Oznacza to, że wszystkie żądania dotyczące sesji HTTP muszą być przetwarzane przez ten sam węzeł klastra

Więc gdy sesja jest wymagana, użytkownik musiałby być przypięty do tego węzła. Stwarza to potrzebę inteligentnego równoważenia obciążenia i wpływa na skalowanie, co sprawiło, że Lift nie był rozwiązaniem w moim przypadku. Wybrałem http://www.playframework.org/ i byłem bardzo zadowolony. Jak dotąd Play był stabilny i niezawodny oraz bardzo łatwy w obsłudze.

I nie przyszedł do podnoszenia i Scala z tła Java, więc nie jest to z własnego doświadczenia, ale wiem, że wielu deweloperów wind znaleźć Scala być znacznie bardziej zwięzły i wydajny niż język Java.

Poszerzanie swojej wiedzy jest zawsze opłacalnym przedsięwzięciem :) Dopiero co zacząłem uczyć się Scali, wpływa to na to, jak piszę normalną Javę i mogę powiedzieć, że do tej pory było to bardzo korzystne.

Nienawidzę całkowicie rzucać swoim światem w pętlę. Ale możesz użyć Scala, Java, Lift, Spring w jednej aplikacji i nie ma z tym problemu.

Moim skromnym zdaniem liczy się wyobraźnia.

Rozważmy, że chcesz napisać aplikację. Jeśli jesteś przyzwoitym programistą, aplikacja powinna być już zbudowana w twojej głowie. Następnym krokiem jest odkrycie, jak to działa za pomocą kodu. Aby to zrobić, musisz przekazać wyimaginowaną aplikację przez funkcję, która tłumaczy ją na rzeczywistą aplikację. Ta funkcja jest językiem programowania. Więc

Real app = programming language (imagined app)

Dlatego ważny jest wybór języka. Tak jest z ramami. Jest tu mnóstwo mądrych ludzi, którzy doradzą ci, co wybrać, ale ostatecznie wybór języka / struktury, który najlepiej tłumaczy twoją wyobraźnię, powinien być twój. Więc wykonaj prototyp z obydwoma i dokonaj wyboru.

Jeśli chodzi o mnie, powoli uczę się Scala i Lift i uwielbiam to.

Ale głównym problemem jest to, że nie możemy porównać sprężyny z wyciągiem. Winda jest zasadniczo używana jako struktura interfejsu użytkownika, a Spring jest używana jako struktura DI.
Jeśli tworzysz aplikację internetową, która ma tak dużo zaplecza, możesz użyć windy.
ale jeśli tworzysz aplikację internetową, która ma zaplecze serii i zdecydowanie potrzebujesz wiosny.