Webtoepassingsstructuur en -implementatie

Ons product is een ASP.Net-webapplicatie. Momenteel gebruiken we websiteprojecten in Visual Studio, maar we onderzoeken al geruime tijd webapplicatieprojecten. Ik onderzoek ze momenteel, zodat we hopelijk ons ​​implementatieproces kunnen verbeteren.

We hebben een basiswebsite die wordt gedeeld en gedeeld tussen verschillende klanten, en dat breiden we uit met klantspecifieke functionaliteit in clientwebsiteprojecten. De klantprojecten breiden uit en baseren zich daarom op de inhoud ervan. Om het volledige product te bouwen, implementeren we eerst de basiswebsite en leggen deze vervolgens samen met de inhoud van het clientproject.

Bij het converteren naar webapplicatieprojecten in Visual Studio hoopten we in staat te zijn om het basisproject te maken, vervolgens klantprojecten te maken en verwijzingen naar basis in te stellen. Deze structuur lijkt goed te werken, maar wanneer we proberen de toepassing vanuit het clientproject met behulp van MSDeploy te implementeren, wordt alleen de dll van de basiswebsite gepubliceerd. Dit is goed voor sommige dingen, verwijzingen naar de gecompileerde code is handig, maar er zijn andere items zoals afbeeldingen, js-pagina's, htm, enz. Die nog steeds de bron is die vereist is voor de werking van de clienttoepassing. We hebben meer nodig dan de gecompileerde code van onze basiswebsite.

Dat gezegd hebbende, ik kan hier een paar opties bedenken:

  1. Ga door met implementeren in 2 stappen. Eerst de basiswebsite en vervolgens de klantwebsite om het volledige product te bouwen.
  2. Pas het implementatieproces aan om de vereiste bronbestanden van het basisproject te kopiëren
  3. Ontwerp ons model opnieuw om deze basis-klantrelatie op een andere manier te ondersteunen. Niet helemaal zeker hoe dit zou werken, en zou de minst haalbare optie zijn.
  4. ??

Is er een andere optie die ik mis? Doe ik iets verkeerd met de manier waarop ik mijn projecten opzet? Is er meer om een ​​webtoepassing te laten verwijzen naar een andere webapplicatie dan om gecompileerde code te delen? Als dat het geval is, waarom zou je dan niet gewoon een gedeelde klassenbibliotheek gebruiken? Of mis ik iets met het MS Deploy-proces?

Ik sta open voor suggesties hier omdat ik het gevoel heb dat ik iets mis. Ik denk niet dat ons model voor onze webapplicaties te uniek is.

Update: het dual-deploy-proces werkt, maar voelt een beetje kludgey. Elke andere invoer?

11
heb je lezen over aspnet_merge.exe msdn.microsoft.com/en-us/library /aa479044.aspx
toegevoegd de auteur Imran Rizvi, de bron
Trouwens, ja, je model is ongebruikelijk. Maar loop in ieder geval weg van de website "projecten". Ze zijn uniek en niet op een goede manier.
toegevoegd de auteur John Saunders, de bron
Ik heb er niet eerder aan gedacht om vertakking in dit scenario te gebruiken, maar FYI, de vertakking in TFS 2010 is een stuk gemakkelijker te gebruiken dan in het verleden. Het is de moeite van het bekijken waard. Ik adviseer ook dat u de klantspecifieke delen van uw toepassing zorgvuldig van de gemeenschappelijke delen scheidt en isoleert. Maak specifieke uitbreidings- en aanpassingspunten in de app. Dat maakt het gemakkelijker om te zien hoe dit het beste kan worden ingezet. Er zijn ook leuke trucs die je met MSDEPLOY kunt spelen. Zie amazon.com/Inside-Microsoft-Build-Engine-Foundation/DP/& hellip;
toegevoegd de auteur John Saunders, de bron
Ya, we weten al een tijdje dat websiteprojecten ... umm, "speciaal" op een aantal manieren zijn. Het is soms gewoon moeilijk om iets te repareren dat niet kapot is. Wat maakt onze structuur zo uniek? Een andere denkbare optie is om elk project de volledige bron van de applicatie te laten bevatten en een soort bronvertakking op te zetten. We hebben dat echter al eerder gedaan en het wordt erg moeilijk om veranderingen te behouden.
toegevoegd de auteur yourbuddypal, de bron
Een goed deel van wat ons product uniek maakt, is dat klanten pagina's kunnen hebben die uniek zijn en helemaal niet zijn opgenomen in onze basiswebsite. Dus naast het uitbreiden van de bestaande applicatie, is het ook een aanvulling daarop. Dat is waar ik verward word met uw suggestie van uitbreidingspunten waar we unieke inhoud hebben.
toegevoegd de auteur yourbuddypal, de bron

4 antwoord

Door assemblage WebResource te gebruiken, kunt u CSS/JS/Een ander bestand als referentie toevoegen, samen met de Code, d.w.z., uw Base Project DLL.

Als u gelijk hebt, kunt u deze WebResource toevoegen aan uw basisproject en vervolgens de onderstaande link gebruiken.

http://support.microsoft.com/kb/910442

Op deze manier hebben de meeste hulpprogramma's van derden toegang tot hun CSS- en JS-bestanden.

Probeer dit. Ik hoop dat het zal helpen.

1
toegevoegd

Als ik uw vraag goed heb begrepen, wilt u ook items publiceren die niet zijn gecompileerd (htm, JS, afbeeldingen, enz.).

So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).

Ik denk dat de build-actie "inhoud", met de optie "kopie naar uitvoerdirectory" ingesteld op "kopiëren als nieuwer", mogelijk de oplossing is waarnaar u op zoek bent.

0
toegevoegd

Hoe wordt de site tussen klanten gedeeld? Krijgt elke klant uiteindelijk een andere site (ip-adres, enz.) Of loggen ze in op dezelfde site maar krijgen ze andere functies? Misschien wilt u kijken naar het toevoegen van ALLE functionaliteit in een enkel project en vervolgens het inschakelen/uitschakelen van de functie via instellingen.

0
toegevoegd

Ik zou zorgvuldig analyseren wat je deelt tussen projecten en hoe je ze deelt.

Als het gecompileerde code is, is de juiste manier om die klassen uit te pakken in hun eigen naamruimte en assembly en de DLL over projecten te delen. Zorg ervoor dat je OO en SOLID principes volgt tijdens het refactoren.

Als het inhoud (js, htm, afbeeldingen, CSS) is die je deelt, heb je hier een paar opties. U kunt een afzonderlijke virtuele map voor de inhoud maken en naar uw inhoud verwijzen met een absolute URL. Dit helpt, want later in de rij als u ooit een project in zijn eigen website in IIS wilt scheiden, hoeft u de content-URL's niet te wijzigen. U kunt ook alle inhoud op uw zogenaamde basiswebsite hebben en vervolgens verwijzen naar de inhoud in de andere projecten met een relatief pad ten opzichte van de basissite.

Aan de andere kant, als het ASP.NET-gebruikersbesturingselementen of ASP.NET MVC-weergaven zijn die u wilt delen, kunt u het beste een afzonderlijk item in elk project maken. Dit betekent niet noodzakelijkerwijs dat er een afzonderlijk fysiek bestand in dat pad is - u kunt ook items in een .NET-project in Visual Studio toevoegen die alleen verwijzingskoppelingen zijn.

Wat het implementatieproces betreft, denk ik niet dat er iets mis is met de websiteprojecten op zich. Websiteprojecten hebben een ander doel dan webtoepassingsprojecten, met als belangrijkste dat u uw klassen niet telkens hoeft te compileren wanneer u code implementeert (mits ze zich in de juiste toepassingsmappen bevinden). Ik zou willen voorstellen om vast te houden aan het tweestapsimplementatieproces met websiteprojecten.

Ik zou ook de websites (virtuele mappen) bekijken die in IIS zijn gemaakt en overwegen om ze te nesten als dit logisch is. En een beoordeling van de groepen van toepassingen (ongeacht of deze gescheiden of gedeeld zijn) zou ook geen schade aanrichten.

Ten slotte is dit een oude vraag. Deel dit alsjeblieft als je al een succesvolle strategie hebt geïmplementeerd.

0
toegevoegd