Jeśli chcesz, aby przejść bezpośrednio do kodu jsFiddle, to tutaj: http://jsfiddle.net/bbkxK/2/Czy mogę zastąpić wiązania określone na poziomie klasy w instancji?
Idealnie byłoby oczekiwać, obie instancje obiektów do wyjścia „coś innego” dla theMessage.
Oto kontekst: Mamy ogromną aplikację Ember i chcemy zastosować podejście oparte na konwencji poprzez określenie odpowiednich domyślnych powiązań z globalnymi singletonami w naszych definicjach klas (jeśli chcesz wyjść na styczną i twierdzą, że to okropne i jest lepszy sposób, jestem uszy, nie kocham naszej obecnej architektury, ale podąża za wzorcami przedstawionymi przez deweloperów Embera za pośrednictwem przykładowych aplikacji).
Wyznaczamy domyślne powiązania, które "działają" w uruchomionej aplikacji. A do tej pory wszystko jest w porządku. Problem polega na rozpoczęciu testów jednostkowych. Kiedy osiągnęliśmy około 500 testów jednostkowych, zaczęliśmy mieć problemy z izolacją testową. Niektóre testy aktualizowałyby stan pojedynczego kontrolera, a następnie inne testy zaczynałyby zawieść. W ciągu ostatnich kilku tygodni zmieniło się to w wielki bałagan i czas.
Aby odizolować testy, rozpoczęliśmy próby nadpisania domyślnych powiązań określonych na poziomie klasy w instancjach testowanych, które tworzyliśmy w naszych testach jednostkowych. Często próbowaliśmy zastąpić wiązanie singleton statycznym odwołaniem do fałszywego obiektu. Ze mną do tej pory?
Po wykonaniu wielu, wielu różnych podejść, najlepszą strategią, jaką wymyśliłem do tej pory, jest wzór MyApp.classWithDeferredDefaultBindings, który można zobaczyć w przykładzie jsFiddle (http://jsfiddle.net/bbkxK/2/).
Ale ... jest o wiele bardziej gadatliwy niż normalny sposób działania Embera i po prostu nie jest w porządku. Sądzę, że moglibyśmy stworzyć Ember z patchinsem lub małpkami, aby było lepiej, ale wydawało się, że powinniśmy dotrzeć do społeczności deweloperów, zanim podejmiemy ten krok.
Tak więc moje wieloosobowe pytanie brzmi: czy nasze podejście jest uzasadnione dla nadpisania domyślnych wiązań singleton w kontekście testu jednostkowego? Czy powinniśmy wysłać prośbę o funkcję do Ember, aby bardziej płynnie to poprzeć? Czy możesz twierdzić, że to błąd w strukturze?
Trudno jest uchwycić mój problem w prostym jsFiddle. Staramy się nie używać singletonów w testach, ale mamy problemy z zastąpieniem domyślnych powiązań. Myślę, że to rozszczepia włosy, mówisz, nie ustawiaj domyślnych powiązań. W większości się zgadzam, ale mamy ponad 500 klas (baza kodów jest rzędu 100 000 linii), a okablowanie wszystkiego podczas inicjalizacji staje się trudne. To, czego naprawdę chcemy, to jakiś system zależności injenction, w którym znajduje się singleton i jest automatycznie wiązany, jeśli * nie * zostanie przesłonięty w testach jednostkowych. Właśnie tego staramy się osiągnąć za pomocą tego wiążącego wzoru. –
Należy również dodać, że w widokach zagnieżdżonych nie chcę, aby widok nadrzędny wymagał znajomości wszystkich zależności z kontrolerami i innymi jednostkami podobnymi do singletonu w jego widokach podrzędnych, i ustawić je wszystkie podczas tworzenia instancji widoków (który zwykle jest bardzo dynamiczny). Dlatego w naszych poglądach używamy kontrolowania kontrolek: "..." i to jest główny obszar, w którym mamy problemy z pisaniem stabilnych, izolowanych testów. Ale kiedy próbuję to wszystko wyjaśnić, staję się bardziej pewny, że nie powinniśmy tutaj w ogóle używać wiązań. To na pewno niepotrzebne uderzenie wydajności. Myślę, że wracam do deski kreślarskiej. –
Pierwotne pytanie tutaj jest w zasadzie nieprawidłowe. Mamy luki w architekturze i powinniśmy przestać określać powiązania z globalną przestrzenią nazw na poziomie klasy. –