Czy mogę osadzać pliki CSS/JavaScript w aplikacji internetowej?

Question

Niedawno zacząłem umieszczać pliki JavaScript i CSS w naszych wspólnych bibliotekach DLL, aby ułatwić wdrażanie i wersjonowanie. Zastanawiam się tylko, czy istnieje jakikolwiek powód, dla którego ktoś mógłby chcieć zrobić to samo z aplikacją internetową, czy też zawsze najlepiej zostawić je jako zwykłe pliki w aplikacji sieciowej i używać jedynie zasobów osadzonych dla współdzielonych komponentów?

Czy istnieje jakaś korzyść z ich osadzania?

Answer 1

Oczywiście, jeśli ktoś, kto wiedział, co robią, może użyć reflektora montażowego i wydobyć JS lub CSS. Ale byłoby to o wiele więcej pracy niż użycie czegoś takiego jak FireBug, aby uzyskać te informacje. Zwykły użytkownik końcowy raczej nie będzie chciała pójść na te wszystkie kłopoty tylko po to, by zepsuć zasoby. Każdy, kto jest zainteresowany tym typem, może być złośliwym użytkownikiem, a nie użytkownikiem końcowym. Prawdopodobnie masz wiele innych problemów związanych z bezpieczeństwem, jeśli użytkownik może użyć narzędzia takiego jak reflektor montażowy w bibliotece DLL, ponieważ w tym momencie twój serwer został już przejęty. Bezpieczeństwo nie było czynnikiem w mojej decyzji o osadzeniu zasobów.

Chodziło o to, aby uniemożliwić użytkownikom robienie czegoś głupio z tymi zasobami, na przykład usunąć je, uważając, że nie są potrzebne lub w inny sposób naruszają ich.

Dużo łatwiej jest spakować aplikację do celów związanych z wdrażaniem, ponieważ w grę wchodzi mniej plików.

To prawda, że ​​biblioteka DLL (biblioteka klas) używana przez strony jest większa, ale nie zwiększa to rozmiaru stron. ASP.NET generuje zawartość, która musi zostać przesłana do klienta (przeglądarki). Nie ma więcej treści wysyłanych do klienta, niż to, co jest potrzebne do działania strony. Nie widzę, w jaki sposób biblioteka klas, pomagając w obsłudze tych stron, będzie miała jakikolwiek wpływ na rozmiar danych przesyłanych między klientem a serwerem.

Jednak Rjlopes ma rację, może być prawdą, że przeglądarka nie może buforować osadzonych zasobów JavaScript/CSS. Będę musiał to sprawdzić, ale podejrzewam, że Rjlopes jest poprawny: pliki JavaScript/CSS będą musiały być pobierane za każdym razem, gdy na serwer zostanie wysłane odświeżenie całej strony. Jeśli okaże się to prawdą, to trafienie wydajnościowe powinno być czynnikiem w twojej decyzji.

Nadal nie byłem w stanie przetestować różnic wydajności między używaniem zasobów osadzonych, resex i pojedynczych plików, ponieważ byłem zajęty moimi staraniami. Mam nadzieję, że dokończę to dzisiaj, ponieważ jestem bardzo ciekawy tego i punkt buforowania przeglądarki, który podniósł Rjlopes.

Answer 2

Powód umieszczenia: Przeglądarki nie pobierają równolegle plików JavaScript. Masz warunek blokowania, dopóki plik nie zostanie pobrany.

Powód przed zatopieniem: może nie być potrzebny cały kod JavaScript. Więc możesz niepotrzebnie zwiększać przepustowość/przetwarzanie.

Answer 3

Musiałem podjąć tę samą decyzję raz. Powodem, dla którego zdecydowałem się umieścić moje zasoby JavaScript/CSS w mojej bibliotece DLL, było zapobieganie manipulowaniu tymi plikami (przez ciekawych użytkowników końcowych, którzy kupili moją aplikację internetową) po wdrożeniu aplikacji.

Wątpię i kwestionuję ważność komentarza Usprawnienia o tym, w jaki sposób przeglądarki pobierają pliki JavaScript. Jestem prawie pewien, że osadzone pliki JavaScript/CSS są tymczasowo odtwarzane przez ASP.NET zanim strona zostanie wysłana do przeglądarki, aby przeglądarka mogła je pobrać i wykorzystać. Ciekawi mnie to i zamierzam przeprowadzić własne testy. Dam ci znać jak poszło ....

-Frinny

Answer 4

Wiesz, że jeśli ktoś chce manipulować swoimi JS i CSS po prostu trzeba otworzyć zespół z reflektorem, przejdź do zasobów i edytuj to, czego oczekują (prawdopodobnie wymaga to dużo więcej pracy, jeśli złożenia są podpisane).

Jeśli osadzisz js i css na stronie, która powiększysz stronę (więcej KB do pobrania na każde żądanie), a przeglądarka nie będzie w stanie buforować JS i CSS dla następnych żądań. Dobrą wiadomością jest to, że masz mniej zgłoszeń (przynajmniej 2, jeśli jesteś podobny do mnie i łączą wiele js i css i jeden), a javascripts mają problem z pobieraniem seryjnym.

Answer 5

Jeśli chodzi o pamięć podręczną przeglądarki, o ile wiem, odpowiedź na WebRecource.axd mówi "304 niezmodyfikowany". Sądzę, że zostali zabrani z pamięci podręcznej.

Answer 6

Musiałem podjąć tę samą decyzję raz. Powodem, dla którego zdecydowałem się umieścić moje zasoby JavaScript/CSS w mojej bibliotece DLL, było zapobieganie manipulowaniu tymi plikami (przez ciekawych użytkowników końcowych, którzy kupili moją aplikację internetową) po wdrożeniu aplikacji. Powód przed zatopieniem: może nie być potrzebny cały kod JavaScript. Więc możesz niepotrzebnie zwiększać przepustowość/przetwarzanie.