2013-02-23 15 views
11

To może brzmieć jak głupie pytanie na powierzchni, ale dlaczego Hot Towel SPA Template w ogóle zawiera Breeze?Dlaczego HotTowel zawiera Breeze?

Ostatnie kilka dni spędziłem na uczeniu się Hot Towela i jego zależności. O ile wiem, nic w szablonie nie używa Breeze. Być może to się zmieni wraz z przyszłym wydaniem?

Jasne, Breeze to dobra biblioteka. Ale wiąże się to z metodologią CRUD i wymaga zaprojektowania ApiControllers w określony sposób. (Metadane, SaveChanges, itp.) see here

To również prowadzi użytkownika do Entity Framework. Chociaż jest to bardziej zależność od miękkich, ponieważ Breeze pokazuje również a sample without it, nadal prowadzi użytkownika do podobnego wzorca implementacji przy użyciu zmodyfikowanego wzorca repozytorium.

Jeśli używasz magazynów danych NoSQL lub wzorców CQRS zamiast CRUD, wówczas Breeze staje się bardzo trudny w użyciu. Istnieją alternatywne biblioteki dostępu do danych, które działają dobrze w tym stylu, takie jak AmplifyJS.

Ale reszta Hot Towel jest doskonała! Szczególnie lubię Durandala. Pytanie nasuwa się, jeśli szablon faktycznie nie robi żadnego dostępu do danych - dlaczego w ogóle zawiera komponent dostępu do danych? Byłoby lepiej wysłać go bez Breeze, a jeśli użytkownik końcowy chce używać Breeze, Amplify lub cokolwiek innego - niech tak będzie. Reszta Hot Towel nadal będzie świecić jako świetna realizacja SPA.

Odpowiedz

18

Matt - Dobre pytanie. Odkąd to stworzyłem, myślę, że powinienem odpowiedzieć :)

Kiedy zbudowałem szablon, skupiłem się na zapewnieniu wystarczającej ilości osób, które będą korzystać z właściwych narzędzi i wystarczającej ilości kodu startowego, który wskaże drogę. Nie chciałem, żeby ktoś wyrzucił kod. Nie jestem fanem szablonów, które zaczynają od ścieżki i sprawiają, że usuwasz mnóstwo plików i kodu oraz zmieniasz kierunek. To są próbki.

Próbki są dobre. W rzeczywistości próbki mogą być doskonałe (podobnie jak inne szablony, które moim zdaniem są bardziej podobne do próbek). Te służą innym celom: pokazać, jak możesz robić różne rzeczy.

Powrót do szablonu Hot Towel ... jeśli dołączę kod wykorzystujący Breeze, byłbym skłonny do dodania do klienta pliku datacontext.js i model.js. Zawierałyby kod dostępu do danych i kod w celu rozszerzenia modeli na kliencie. Wtedy chciałbym dodać kontroler, niektóre modele po stronie serwera, ORM i bazę danych. Będąc tam, chciałbym użyć danych na wielu ekranach, co prowadzi mnie do bardziej Knockout i buforowania z Breeze. Wtedy mógłbym pokusić się o dodanie edycji, która doprowadziłaby do zmiany śledzenia. Wkrótce mam pełną wersję aplikacji. Lub bardziej zachowawczo, mam próbkę ponownie. Chociaż te metody dostarczałyby więcej wskazówek, jak je zestawić, nie pomogłyby Ci "zacząć" od szablonu, w którym można po prostu zacząć budować i dodawać własny kod. Jeśli zatrzymam się przed niektórymi z tych funkcji, nadal chodzę po drodze, która wymaga zmiany sposobu, w jaki to zrobiłem.

W obecnej postaci HotTowel jest bardzo podobny do szablonu w najprawdziwszym znaczeniu. Tworzysz nowy projekt i jesteś wyłączony i dodajesz swój własny kod.

Można argumentować (i być może), że Breeze nie powinno tam być, ponieważ nie używam go w szablonie. Nie używam też pliku moment.js, BTW. Twierdzę jednak, że obie są doskonałymi bibliotekami, że bez nich nie chciałbym budować SPA na bazie CRUD. Breeze jest elastyczny, jak sugerujesz, więc nie musisz chodzić konkretną ścieżką.

Najlepszym sposobem zrozumienia wartości Breeze jest zbudowanie aplikacji, która ma swoje funkcje, ale bez Breeze. Następnie możesz zobaczyć, ile kodu zajmuje i jak jest zaangażowany. Na jednym takim przykładzie, patrz mój kurs pośredni poziom spa w Pluralsight gdzie zrobić dokładnie to: „Dlaczego Breeze” http://jpapa.me/spaps

Więc pytasz ... ponieważ gorąco polecam go do budowy SPA.

Dzięki za pytanie i powodzenia!

+2

Na marginesie ... Wzmocnienie, choć fantastyczne, nie zbliża się do tego, co robi Breeze. –

+2

Dzięki za szczegółową odpowiedź. Sądzę, że używam Hot Towel bardziej jak próbny starter niż szablon. Widzę jednak twoje punkty. Dla mnie Breeze wchodzi w drogę, ponieważ mam już bogatą sieć WebAPI do połączenia. Dla innych być może jest lepiej. Świetnie spisałeś się przy układaniu Durandala, a powłoka Hot Towel jest wyjątkowo ostra. Łatwo było mi wymienić części, których nie chciałem, więc wszystko jest w porządku. Poważnie - zaoszczędziło mi to wiele kłopotów. Dziękuję Ci!!! –

+0

+1 W tym moment.js. Doskonała biblioteka. –

7

Dzięki za pytanie.

John, jako autor HT, zaoferował odpowiedź. Ja, jako dyrektor projektu Breeze, jestem skłonny się z nim zgodzić :)

HotTowel tworzy podstawę, na której możesz się oprzeć. To nie jest sam budynek.

Jest to podstawa przeznaczona dla konkretnego rodzaju aplikacji, aplikacji CRUD opartej na specyficznym zestawie współpracujących technologii JavaScript i ASP.NET. Breeze jest współtwórcą ... ale nie jedynym. Knockout, ze swoją konstrukcją MVVM i dwukierunkowym wiązaniem danych, jest szczególnie dobrze dostosowany do zadań wprowadzania danych typowych dla aplikacji CRUD.

Oczywiście istnieją inne rodzaje SPA. Istnieje ważna klasa aplikacji, które w większości prezentują informacje i akceptują niewielki wkład użytkownika. Takie aplikacje nie odnoszą tak dużego pożytku z powiązania danych, a ludzie, którzy je piszą, mogą być dość wrogo nastawieni do powiązań danych w ogóle, a w szczególności do KO.

Chodzi mi o to, że HT jest ukierunkowany na określoną klasę aplikacji ... która jest ogromnie udana, przynajmniej jeśli mierzy się ją ciągłą popularnością. Dostarcza towary dla osób, które budują te aplikacje. To może nie być właściwe miejsce początkowe dla innych rodzajów aplikacji.

To prawda, że ​​prosta droga do Breeze przebiega przez Web API, EF i relacyjną bazę danych. Zabierz je i możesz napisać więcej kodu na serwerze (i trochę więcej na kliencie). To może być idealny kompromis dla ciebie.

Autorzy Breeze chcieliby ułatwić tę drogę. Nie sądzę, BreezeJS sprawia, że ​​trudniej. Nie rozumiem twojego oświadczenia "Powiew staje się bardzo trudny w użyciu." Próbowałeś tego?

Twój klient może komunikować się z dowolnym zasobem HTTP w dowolny sposób. Łatwo jest używać istniejących kontrolerów Web API (choć łatwiej z kontrolerami Breeze Web API). Możesz użyć amplify.js, jeśli wolisz (btw, możesz powiedzieć Breeze, aby wykonywał połączenia AJAX ze wzmocnieniem). Nie musisz nawet używać Breeze EntityManager do wysyłania zapytań i zapisywania danych, jeśli nie chcesz tego robić.

Reszta BreezeJS może nadal mieć wartość dla Ciebie. Pozostaje wiele pracy do wykonania po tym, jak zorientujesz się, jak będziesz pobierać i przechowywać dane oraz czy wolisz styl Entity-ChangeSet czy styl Command/Query.

Będziesz musiał znaleźć odpowiedzi na te pytania:

  • Jak będzie kształtować surowych danych JSON do Bindable obiektów?
  • W jaki sposób utrzymasz te obiekty i udostępnisz je na wielu ekranach, nie robiąc zbędnych podróży do serwera?
  • W jaki sposób będzie można przechodzić od jednego obiektu do powiązanego obiektu, tak jak w przypadku wiązania adresu z combobox StatesAndProvinces?
  • Jak będziesz śledzić zmiany?
  • W jaki sposób je zatwierdzisz?
  • Jak przechowywać niektóre lub wszystkie dane w pamięci lokalnej, gdy aplikacja "nagrobki"?

Breeze może pomóc w tych obowiązkach, nawet jeśli nie chcesz, aby zapytanie i oszczędzanie dla Ciebie.

A jeśli odpowiedź pozostaje „Zrobię wszystko to ja dziękuję” ... dobrze, usuwając Breeze z projektu HotTowel jest tak proste, jak:

Uninstall-Package breeze.webapi

+5

Chciałbym zobaczyć próbkę Breeze w niektórych istniejących kontrolerach Web API ... być może Matt i Ward mogą spojrzeć na to razem. Byłoby interesujące zobaczyć wyniki. –

+0

Dzięki za punkt widzenia. Tak - próbowałem bryzy i zgadzam się, że ma ogromną wartość dla poszczególnych typów aplikacji. Biblioteka klienta jest świetna. Części, z którymi mam problemy, są po stronie serwera. 'IQueryable' with OData jest świetny, ale' SaveChanges() 'i' MetaData() 'są zbyt zastrzeżone dla mojego gustu. Nadal będę próbować [adaptować próbkę NoDb dla RavenDB] (https://breezejs.uservoice.com/forums/173093/suggestions/3233261), ale wydaje się to nieco ograniczające na powierzchni. Mam nadzieję udowodnić, że się mylę. :) –

+6

Kolejna kwestia - chcę móc używać tego samego punktu końcowego WebAPI zarówno do tworzenia własnych aplikacji, jak i do udostępniania moim klientom pakietu SDK dla programistów do łączenia się z serwerem zaplecza. Moja aplikacja nie powinna mieć żadnego specjalnego dostępu i nie chcę zmuszać innych do korzystania z bryzy. Mogą być na innej platformie całkowicie. Może jest jakiś wzór na pogodzenie tego, o czym nie myślałem? –

Powiązane problemy