Witryna sieci Web ASP.NET lub aplikacja sieci Web ASP.NET?

Kiedy uruchamiam nowy projekt ASP.NET w programie Visual Studio, mogę utworzyć aplikację sieci Web ASP.NET lub witrynę sieci Web ASP.NET.

Jaka jest różnica między aplikacją sieci Web ASP.NET a witryną sieci Web ASP.NET? Dlaczego miałbym wybierać jeden nad drugim?

Czy odpowiedź różni się w zależności od używanej wersji programu Visual Studio?

Stronie internetowej:

Projekt strony internetowej jest kompilowany w locie. W rezultacie powstaje o wiele więcej plików DLL, co może być uciążliwe. Daje to również problemy, gdy masz strony lub kontrolki w jednym katalogu, które muszą odnosić się do stron i kontrolek w innym katalogu, ponieważ drugi katalog może nie zostać jeszcze skompilowany w kodzie. Innym problemem może być publikowanie.

Jeśli nie powie się Visual Studio, aby stale używał tych samych nazw, pojawi się nowa nazwa dla plików DLL generowanych przez strony przez cały czas. Może to prowadzić do posiadania kilku bliskich kopii plików DLL zawierających tę samą nazwę klasy, co wygeneruje wiele błędów. Projekt witryny sieci Web został wprowadzony w programie Visual Studio 2005, ale okazało się, że nie jest popularny.

Aplikacja internetowa:

Projekt aplikacji sieci Web został utworzony jako dodatek i obecnie istnieje jako część dodatku SP 1 dla programu Visual Studio 2005. Główne różnice polegają na tym, że projekt aplikacji sieci Web został zaprojektowany tak, aby działał podobnie do projektów sieci Web dostarczanych z programem Visual Studio 2003. Będzie skompiluj aplikację w jednym pliku DLL podczas kompilacji. Aby zaktualizować projekt, należy go ponownie skompilować i opublikować plik DLL, aby nastąpiły zmiany.

Kolejną przyjemną cechą projektu aplikacji sieciowej jest to, że znacznie łatwiej jest wykluczyć pliki z widoku projektu. W projekcie witryny sieci Web nazwa każdego wykluczanego pliku jest zmieniana na wykluczone słowo kluczowe w nazwie pliku. W projekcie aplikacji sieciowej projekt śledzi tylko, które pliki mają zostać uwzględnione / wykluczone z widoku projektu bez zmiany ich nazwy, co znacznie poprawia porządek.

Odniesienie

W artykule ASP.NET 2.0 - Projekt witryny sieci Web a aplikacji sieci Web podano również powody, dla których warto używać jednego, a nie drugiego. Oto jego fragment:

• Chcesz przeprowadzić migrację dużych aplikacji Visual Studio .NET 2003 do VS 2005? użyj projektu aplikacji sieci Web.
• Chcesz otworzyć i edytować dowolny katalog jako projekt sieciowy bez tworzenia pliku projektu? użyj projektu strony internetowej.
• Musisz dodać kroki przed kompilacją i po kompilacji? użyj projektu aplikacji sieci Web.
• Potrzebujesz zbudować aplikację internetową przy użyciu wielu projektów internetowych? użyj projektu aplikacji sieci Web.
• Chcesz wygenerować jeden zespół dla każdej strony? użyj projektu strony internetowej.
• Wolisz dynamiczną kompilację i pracę na stronach bez budowania całej witryny przy każdym wyświetleniu strony? użyj projektu strony internetowej.
• Wolisz jednostronicowy model kodu niż model kodu? użyj projektu strony internetowej.

Projekty aplikacji internetowych a projekty witryn internetowych (MSDN) wyjaśniają różnice między projektami witryn internetowych i aplikacji internetowych. Omówiono także konfigurację, która ma zostać wykonana w programie Visual Studio.

Witryna sieci Web jest wdrażana na serwerze sieci Web ASP.NET, takim jak IIS. Tylko kilka plików i folderów. W witrynie sieci Web nie ma nic, co wiązałoby Cię z programem Visual Studio (nie ma pliku projektu). Generowanie kodu i kompilacja stron internetowych (takich jak .aspx, .ascx, .master) odbywa się dynamicznie w czasie wykonywania , a zmiany w tych plikach są wykrywane przez środowisko i automatycznie kompilowane ponownie. Możesz umieścić kod, który chcesz udostępnić między stronami, w specjalnym folderze App_Code lub możesz go wstępnie skompilować i umieścić zespół w folderze Bin.

Aplikacja internetowa to specjalny projekt Visual Studio. Główną różnicą w stosunku do witryn sieci Web jest to, że podczas tworzenia projektu wszystkie pliki kodu są kompilowane w jednym zestawie, który jest umieszczony w katalogu bin. Nie wdrażasz plików kodu na serwerze WWW. Zamiast specjalnego folderu dla współdzielonych plików kodu możesz je umieścić w dowolnym miejscu, tak jak w bibliotece klas. Ponieważ aplikacje sieci Web zawierają pliki, których nie należy wdrażać, takie jak pliki projektu i kodu, w programie Visual Studio istnieje polecenie Opublikuj, aby wyprowadzić witrynę sieci Web do określonej lokalizacji.

App_Code vs Bin

Wdrażanie współdzielonych plików kodu jest ogólnie złym pomysłem, ale to nie znaczy, że musisz wybrać aplikację internetową. Możesz mieć witrynę sieci Web, która odwołuje się do projektu biblioteki klas, który zawiera cały kod witryny sieci Web. Aplikacje internetowe to tylko wygodny sposób na zrobienie tego.

CodeBehind

Ten temat dotyczy plików .aspx i .ascx. Temat ten ma coraz mniejsze znaczenie w nowych ramach aplikacji, takich jak ASP.NET MVC i strony sieci Web ASP.NET, które nie używają plików typu codebehind.

Poprzez wszystkie pliki kod skompilowany w jednym zespole, w tym kodzie plików .aspx stron i .ascx kontroli, w Web Applications trzeba odbudować dla każdej małej zmianie i nie można dokonać zmian na żywo. Może to być bardzo uciążliwe podczas programowania, ponieważ trzeba ciągle przebudowywać, aby zobaczyć zmiany, podczas gdy w przypadku witryn sieci Web zmiany są wykrywane przez środowisko wykonawcze, a strony / elementy sterujące są automatycznie rekompilowane.

Zarządzanie środowiskiem wykonawczym zespołów kodu jest mniej pracy, ponieważ nie musisz martwić się o nadawanie stronom / kontrolkom unikalnych nazw lub organizowanie ich w różne przestrzenie nazw.

Nie twierdzę, że wdrażanie plików kodu jest zawsze dobrym pomysłem (szczególnie nie w przypadku plików kodu współużytkowanego), ale pliki typu codebehind powinny zawierać tylko kod, który wykonuje zadania specyficzne dla interfejsu użytkownika, procedury obsługi zdarzeń podłączania itp. Twoja aplikacja powinna być warstwowe, aby ważny kod zawsze trafiał do folderu Bin. W takim przypadku wdrożenie plików typu codebehind nie powinno być uważane za szkodliwe.

Kolejnym ograniczeniem aplikacji internetowych jest to, że można używać tylko języka projektu. Na stronach internetowych możesz mieć kilka stron w języku C #, niektóre w VB itp. Nie ma potrzeby specjalnej obsługi programu Visual Studio. To właśnie piękno rozszerzalności dostawcy kompilacji.

Ponadto w aplikacjach internetowych nie wykrywa się błędów na stronach / kontrolkach, ponieważ kompilator kompiluje tylko klasy kodu, a nie kod znaczników (w MVC można to naprawić za pomocą opcji MvcBuildViews), która jest kompilowana w czasie wykonywania.

Visual Studio

Ponieważ aplikacje sieci Web są projektami Visual Studio, niektóre funkcje są niedostępne w witrynach sieci Web. Na przykład można użyć zdarzeń kompilacji do wykonania różnych zadań, np. Zminimalizowania i / lub łączenia plików JavaScript.

Kolejną przyjemną funkcją wprowadzoną w Visual Studio 2010 jest transformacja Web.config .Nie jest to również dostępne na stronach internetowych. Teraz działa z witrynami sieci Web w VS 2013.

Budowanie aplikacji internetowej jest szybsze niż budowanie witryny internetowej, szczególnie w przypadku dużych witryn. Wynika to głównie z tego, że aplikacje sieci Web nie kompilują kodu znaczników. W MVC, jeśli ustawisz MvcBuildViews na wartość true, wówczas kompiluje kod znaczników i otrzymujesz wykrywanie błędów, co jest bardzo przydatne. Wadą jest to, że za każdym razem, gdy tworzysz rozwiązanie, buduje ono kompletną witrynę, która może być powolna i nieefektywna, szczególnie jeśli nie edytujesz witryny. Zauważyłem, że włączam i wyłączam MvcBuildViews (co wymaga odciążenia projektu). Z drugiej strony, dzięki Witrynom internetowym możesz wybrać, czy chcesz zbudować witrynę jako część rozwiązania, czy nie. Jeśli nie, budowanie rozwiązania jest bardzo szybkie i zawsze możesz kliknąć węzeł Witryny sieci Web i wybrać Kompiluj, jeśli dokonałeś zmian.

W projekcie aplikacji sieciowej MVC masz dodatkowe polecenia i okna dialogowe do typowych zadań, takich jak „Dodaj widok”, „Przejdź do widoku”, „Dodaj kontroler” itp. Nie są one dostępne na stronie internetowej MVC.

Jeśli używasz IIS Express jako serwera programistycznego, w witrynach internetowych możesz dodawać katalogi wirtualne. Ta opcja nie jest dostępna w aplikacjach internetowych.

Przywracanie pakietów NuGet nie działa w witrynach sieci Web, musisz ręcznie zainstalować pakiety wymienione na pakietach.configPrzywracanie pakietów działa teraz z witrynami sieci Web od wersji NuGet 2.7

Witryna internetowa = użyj, gdy witryna jest tworzona przez grafików, a programiści edytują tylko jedną lub dwie strony

Aplikacja internetowa = użyj, gdy aplikacja jest tworzona przez programistów, a graficy edytują tylko jedną lub dwie strony / obrazy.

Strony internetowe mogą być obsługiwane przy użyciu dowolnych narzędzi HTML bez konieczności posiadania studia programistycznego, ponieważ pliki projektu nie muszą być aktualizowane itp. Aplikacje internetowe są najlepsze, gdy zespół w większości korzysta ze studia programistycznego, a zawartość jest wysoka.

(Niektóre błędy kodowania są wykrywane w aplikacjach internetowych w czasie kompilacji, których nie można znaleźć w witrynach sieci Web do czasu wykonania).

Ostrzeżenie: napisałem tę odpowiedź wiele lat temu i od tego czasu nie korzystałem z Asp.net. Oczekuję, że sprawy potoczyły się dalej.

O ile nie potrzebujesz konkretnie dynamicznie skompilowanego projektu, nie używaj projektu strony internetowej .

Dlaczego? Ponieważ projekt strony internetowej popchnie cię do ściany, gdy będziesz próbował zmienić lub zrozumieć swój projekt. Funkcje wyszukiwania statycznego podczas pisania (np. Znajdź zastosowania, refaktor) w Visual Studio będą działać na zawsze w każdym projekcie o rozsądnych rozmiarach. Aby uzyskać więcej informacji, zobacz pytanie Przepełnienie stosu Powolne „Znajdź wszystkie referencje” w Visual Studio .

Naprawdę nie rozumiem, dlaczego porzucili aplikacje internetowe w Visual Studio 2005 dla wywołującego ból, zdrowego rozsądku i produktywnego projektu strony internetowej.

W MSDN znajduje się artykuł opisujący różnice:

Porównywanie projektów witryn internetowych i projektów aplikacji internetowych

BTW: istnieją podobne pytania na ten temat, np .:

• Witryna sieci Web a aplikacja sieci Web ASP.Net w programie Visual Studio Uwaga: została usunięta, nie jest już dostępna w wersji SO
• strona internetowa lub aplikacja internetowa w.ASP.NET

Może się to wydawać nieco oczywiste, ale myślę, że jest to coś, co jest źle rozumiane, ponieważ Visual Studio 2005 był dostarczany tylko z oryginalną stroną internetową. Jeśli Twój projekt dotyczy witryny internetowej, która jest dość ograniczona i nie ma dużej logicznej ani fizycznej separacji, witryna jest w porządku. Jeśli jednak jest to naprawdę aplikacja internetowa z różnymi modułami, w której wielu użytkowników dodaje i aktualizuje dane, lepiej jest z aplikacją internetową.

Największą zaletą modelu witryny jest to, że wszystko w tej app_codesekcji jest dynamicznie kompilowane. Możesz dokonywać aktualizacji plików C # bez pełnego ponownego wdrożenia. Jest to jednak wielka ofiara. Wiele rzeczy dzieje się pod przykryciem, które trudno kontrolować. Przestrzenie nazw są trudne do kontrolowania, a określone użycie DLL domyślnie wychodzi poza okno dla wszystkiego pod, app_codeponieważ wszystko jest dynamicznie kompilowane.

Model aplikacji internetowej nie ma dynamicznej kompilacji, ale zyskujesz kontrolę nad rzeczami, o których wspomniałem.

Jeśli zajmujesz się programowaniem n-warstwowym, bardzo polecam model aplikacji WWW. Jeśli wykonujesz ograniczoną stronę internetową lub szybką i brudną implementację, model strony internetowej może mieć zalety.

Bardziej szczegółową analizę można znaleźć w:

• Projekty aplikacji sieciowych i projekty wdrażania sieci są tutaj
• Witryna lub aplikacja internetowa?

Z książki egzaminacyjnej MCTS 70-515:

Dzięki aplikacji internetowej (projektowi)

1. Możesz utworzyć aplikację MVC.
2. Visual Studio przechowuje listę plików w pliku projektu (.csproj lub .vbproj), zamiast polegać na strukturze folderów.
3. Nie można mieszać Visual Basic i C #.
4. Nie można edytować kodu bez zatrzymania sesji debugowania.
5. Można ustalić zależności między wieloma projektami internetowymi.
6. Musisz zainstalować aplikację przed wdrożeniem, co uniemożliwi testowanie strony, jeśli inna strona nie zostanie skompilowana.
7. Nie musisz przechowywać kodu źródłowego na serwerze.
8. Możesz kontrolować nazwę i wersję zestawu.
9. Nie można edytować poszczególnych plików po wdrożeniu bez ponownej kompilacji.

To zależy od tego, co rozwijasz.

W przypadku witryny zorientowanej na treść jej treść często się zmienia, a witryna jest do tego lepsza.

Aplikacja zazwyczaj przechowuje dane w bazie danych, a strony i kod rzadko się zmieniają. W takim przypadku lepiej jest mieć aplikację internetową, w której wdrażanie zestawów jest znacznie bardziej kontrolowane i ma lepszą obsługę testów jednostkowych.

Compilation Po pierwsze, istnieje różnica w kompilacji. Witryna nie jest wstępnie skompilowana na serwerze, jest kompilowana na plik. Może to być zaletą, ponieważ jeśli chcesz coś zmienić w swojej witrynie sieci Web, możesz po prostu pobrać określony plik z serwera, zmienić go i przesłać ten plik z powrotem na serwer, a wszystko działałoby dobrze. W aplikacji sieciowej nie możesz tego zrobić, ponieważ wszystko jest wstępnie skompilowane i kończy się to tylko jednym dll. Kiedy zmienisz coś w jednym pliku swojego projektu, musisz ponownie wszystko skompilować. Więc jeśli chcesz mieć możliwość zmiany niektórych plików na stronie internetowej serwera, jest lepszym rozwiązaniem dla Ciebie. Pozwala także wielu programistom pracować na jednej stronie internetowej. Z drugiej strony, jeśli nie chcesz, aby twój kod był dostępny na serwerze, powinieneś raczej wybrać aplikację internetową.

Project structure Istnieje również różnica w strukturze projektu. W aplikacji internetowej masz plik projektu taki sam, jak w normalnej aplikacji. Na stronie internetowej nie ma tradycyjnego pliku projektu, wystarczy plik rozwiązania. Wszystkie odniesienia i ustawienia są przechowywane w pliku web.config. @Page directive W dyrektywie @Page istnieje inny atrybut dla pliku zawierającego klasę powiązaną z tą stroną. W aplikacji internetowej jest to standard „CodeBehind”, w witrynie internetowej używasz „CodeFile”. Możesz to zobaczyć w poniższych przykładach:

Aplikacja internetowa:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Stronie internetowej:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Przestrzenie nazw - w powyższym przykładzie widać także inną różnicę - sposób tworzenia przestrzeni nazw. W aplikacji internetowej przestrzeń nazw to po prostu nazwa projektu. W Witrynie istnieje domyślna przestrzeń nazw ASP dla stron dynamicznie kompilowanych.

Edytuj i kontynuuj - w aplikacji internetowej dostępna jest opcja edycji i kontynuacji (aby ją włączyć, musisz przejść do menu Narzędzia, kliknij Opcje, a następnie znajdź Edytuj i kontynuuj w debugowaniu). Ta funkcja nie działa w witrynie sieci Web.ASP.NET MVCI, jeśli chcesz tworzyć aplikacje internetowe

ASP.NET MVC (Model View Controller) najlepszą i domyślną opcją jest aplikacja internetowa. Chociaż możliwe jest użycie MVC na stronie internetowej, nie jest to zalecane.

Podsumowanie - najważniejszą różnicą między aplikacją sieci Web ASP.NET a witryną jest kompilacja. Jeśli więc pracujesz nad większym projektem, w którym kilka osób może go zmodyfikować, lepiej skorzystać ze strony internetowej. Ale jeśli wykonujesz mniejszy projekt, możesz również użyć aplikacji sieci Web.

Tak, aplikacja internetowa jest znacznie lepsza niż strony internetowe, ponieważ aplikacje internetowe dają nam swobodę:

1. Aby mieć wiele projektów pod jednym parasolem i ustalić zależności między projektami. Np. W przypadku PCS możemy śledzić w ramach aplikacji internetowej-

   • Portale internetowe
   • Kontroler powiadomień (do wysyłania wiadomości e-mail)
   • Warstwa biznesowa
   • Warstwa dostępu do danych
   • Menedżer wyjątków
   • Narzędzie serwera
   • Usługi WCF (wspólne dla wszystkich platform)
   • Element listy

2. Aby uruchomić testy jednostkowe kodu zawartego w plikach klas powiązanych ze stronami ASP.NET

3. Aby odnieść się do klas, są one powiązane ze stronami i kontrolkami użytkownika z samodzielnych klas
4. Aby utworzyć pojedynczy zespół dla całej witryny
5. Kontrola nazwy zestawu i numeru wersji generowanej dla serwisu
6. Aby uniknąć umieszczania kodu źródłowego na serwerze produkcyjnym. (Możesz uniknąć wdrażania kodu źródłowego na serwerze IIS. W niektórych scenariuszach, takich jak współdzielone środowiska hostingowe, możesz martwić się nieautoryzowanym dostępem do kodu źródłowego na serwerze IIS. (W przypadku projektu witryny internetowej można uniknąć tego ryzyka, kompilacja wstępna na komputerze programistycznym i wdrażanie wygenerowanych zestawów zamiast kodu źródłowego. W takim przypadku tracisz jednak niektóre zalety łatwych aktualizacji witryny).
7. Problem wydajnościowy z witryną (pierwsze żądanie do witryny może wymagać kompilacji witryny, co może spowodować opóźnienie. A jeśli witryna działa na serwerze IIS, który ma mało pamięci, włączając całą witrynę w pojedynczy zespół może zużywać więcej pamięci, niż byłoby to wymagane w przypadku wielu zespołów).

Jedną z kluczowych różnic jest to, że strony internetowe kompilują się dynamicznie i tworzą zestawy w locie. Aplikacje internetowe kompilują się w jeden duży zestaw.

Rozróżnienie między nimi zostało zniesione w Visual Studio 2008.

Aplikacje są zwykle kompilowane przed wdrożeniem, gdy strona korzysta z katalogu app_code. Gdy coś się zmieni w folderze kodu aplikacji, serwer ponownie skompiluje kod. Oznacza to, że możesz dodawać / zmieniać kod na bieżąco w witrynie.

Zaletą aplikacji jest to, że nie ma ponownej kompilacji, a zatem początkowe czasy uruchamiania będą krótsze.

Polecam obejrzeć wideo Projekty aplikacji internetowych i projekty wdrażania sieci na stronie ASP.NET, które wyjaśniają różnicę bardzo szczegółowo, było to dla mnie bardzo pomocne.

Nawiasem mówiąc, nie daj się zwieść tytułowi, duża część filmu wyjaśnia różnicę między projektami stron internetowych a projektami aplikacji internetowych i dlaczego Microsoft ponownie wprowadził projekty aplikacji internetowych w Visual studio 2005 (jak pewnie już wiesz, to pierwotnie dostarczane tylko z projektami stron internetowych, następnie projekty aplikacji internetowych zostały dodane w SP1). Świetny film, który gorąco polecam każdemu, kto chce poznać różnicę.

„Strona internetowa” ma swój kod w specjalnym katalogu App_Code i jest skompilowana w kilku bibliotekach DLL (zestawach) w czasie wykonywania. „Aplikacja internetowa” jest wstępnie skompilowana w jedną bibliotekę DLL.

Strona internetowa i strona internetowa projektu >> to dwie różne metody tworzenia aplikacji ASP.NET za pomocą visual studio. Jedno jest bezprojektowe, a drugie środowisko projektowe. Różnice są jak

1. Plik rozwiązania jest przechowywany w tym samym katalogu, co katalog główny w środowisku projektu.
2. Konieczne jest usunięcie plików rozwiązania i projektu przed wdrożeniem w środowisku projektu.
3. Pełny katalog główny jest wdrażany w środowisku bez projektu.

nie ma zasadniczej różnicy w stosowaniu obu metod. Ale jeśli tworzysz witrynę internetową, która zajmie więcej czasu, wybierz środowisko projektu.

Model projektu aplikacji sieci Web

• Zapewnia taką samą semantykę projektu sieci Web, jak projekty sieci Web Visual Studio .NET. Ma plik projektu (struktura oparta na plikach projektu). Kompiluj model - cały kod w projekcie jest kompilowany w jednym zestawie. Obsługuje zarówno IIS, jak i wbudowany serwer programistyczny ASP.NET. Obsługuje wszystkie funkcje Visual Studio 2005 (refaktoryzacja, generyczne itp.) Oraz ASP.NET (strony wzorcowe, członkostwo i logowanie, nawigacja w witrynie, motywy itp.). Korzystanie z rozszerzeń serwera FrontPage (FPSE) nie jest już wymagane.

Model projektu witryny sieci Web

• Brak pliku projektu (w oparciu o system plików).
• Nowy model kompilacji.
• Dynamiczna kompilacja i praca na stronach bez budowania całej witryny przy każdym wyświetleniu strony.
• Obsługuje zarówno IIS, jak i wbudowany serwer programistyczny ASP.NET.
• Każda strona ma własny zestaw.
• Odmienny model kodu.

Zawsze zależy to od wymagań klienta. ASP.NET zawiera tylko elastyczne funkcje, których użytkownik potrzebuje do zapewnienia bezpieczeństwa i łatwej konserwacji aplikacji.

Możesz myśleć o aplikacji sieciowej jako pliku binarnym, który działa w środowisku ASP.NET. I strony internetowe jak strony statyczne, które można przeglądać i łatwo wdrożyć do kodu źródłowego.

Ale zalety i wady tych dwóch technologii ASP.NET są dobre.

Strony internetowe - nie zostanie utworzony plik rozwiązania. Jeśli chcemy tworzyć strony internetowe, nie potrzeba studia wizualnego.

Aplikacja internetowa - zostanie utworzony plik rozwiązania. Jeśli chcemy stworzyć aplikację internetową, potrzebne jest studio wizualne. Stworzy pojedynczy .dllplik w folderze bin.

W projektach aplikacji internetowych Visual Studio potrzebuje dodatkowych plików .designer dla stron i elementów sterujących użytkownika. Projekty witryn internetowych nie wymagają tego narzutu. Sam znacznik jest interpretowany jako projekt.

Strona internetowa: automatycznie generuje folder app_code, a jeśli opublikujesz go na serwerze, a następnie, jeśli wprowadzisz jakieś zmiany w jakimkolwiek pliku lub stronie, nie musisz kompilować wszystkich plików.

Aplikacja internetowa Automatycznie generuje plik rozwiązań, którego strona internetowa nie generuje, a jeśli zmienisz jeden plik, musisz skompilować pełny projekt, aby odzwierciedlić jego zmiany.

W aplikacji internetowej można tworzyć warstwy funkcjonalności projektu i tworzyć między nimi zależności, dzieląc je na wiele projektów, ale nigdy nie można tego zrobić na stronie internetowej.

Zdecydowanie aplikacja internetowa, pojedynczy plik DLL i łatwa w utrzymaniu. Ale strona internetowa jest bardziej elastyczna; możesz edytować plik aspx w drodze.

Aplikacje internetowe wymagają więcej pamięci, prawdopodobnie dlatego, że nie masz innego wyboru, jak skompilować w jeden zestaw. Właśnie przekonwertowałem dużą starszą witrynę na aplikację internetową i mam problemy z brakiem pamięci, zarówno w czasie kompilacji, jak i komunikat o błędzie, jak poniżej:

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

błąd, aw czasie wykonywania z tym komunikatem o błędzie, jak poniżej:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Moim zaleceniem do konwersji większych witryn na starszy sprzęt z ograniczoną pamięcią jest wybranie opcji powrotu do modelu strony internetowej. Nawet po początkowym sukcesie problem może pełznąć później.

Tutaj aplikacja wspierająca sieć jest przykładem strony internetowej. Witryna internetowa i aplikacja internetowa mogą być dynamiczne / statyczne, zależy to od wymagań, oto przykład zrozumienia działania witryny i aplikacji internetowej.

Podsumowując niektóre z powyższych odpowiedzi:

Elastyczność , czy możesz wprowadzać zmiany na stronie internetowej?

Strona internetowa : Możliwe. Pro: korzyści krótkoterminowe. Con: długoterminowe ryzyko chaosu projektu.

Aplikacja internetowa : Con: niemożliwe. Edytuj stronę, zarchiwizuj zmiany w kontroli źródła, a następnie skompiluj i wdróż całą witrynę. Pro: utrzymaj projekt wysokiej jakości.

Problemy rozwojowe

Witryna sieci Web : prosta struktura projektu bez pliku .csproj. Dwie strony .aspx mogą mieć tę samą nazwę klasy bez konfliktów. Losowa nazwa katalogu projektu prowadząca do błędów kompilacji, takich jak dlaczego .NET Framework powoduje konflikt z własnym wygenerowanym plikiem i dlaczego .NET Framework powoduje konflikt z własnym wygenerowanym plikiem . Pro: Prosty (uproszczony). Con: nieregularny.

Aplikacja internetowa : Struktura projektu podobna do projektu WebForms, z plikiem .csproj. Nazwy klas stron asp muszą być unikalne. Pro: Prosty (inteligentny). Przeciw: brak, ponieważ aplikacja internetowa jest nadal prosta.