[PHP/COM] Samenwerking tussen ASP.NET en PHP

[XiniX88]

Probleem
Voor mijn stage (overigens geheel onbetaald) moet ik een mix gaan gebruiken indien mogelijk tussen de bestaande.NET programmatuur en PHP. Zover ik uit kon zoeken is dit mogelijk via de COM class of DOTNET class die zich binnen PHP bevind.

Echter op het internet is dermate weinig informatie hierover te vinden dat ik voor aanvang van mijn stage toch als vooronderzoek extra informatie zoek, en bovenal of dit wel mogelijk is.

Gevonden materiaal
Het enige wat ik kon vinden is het volgende:
PHP.net: COM class
PHP.net: DOTNET class
Google: PHP COM
Google: ASP.NET PHP
Google: DOTNET PHP
Hieruit valt echter compleet niet te halen hoe het mogelijk is, vandaar mijn vraag.

Wat er moet komen
Zover ik weet moet dit er zijn voordat ik aan de gang kan

• Windows server
• IIS Webserver
• PHP Plugin

Vragen

1. Kan ik zomaar via PHP .dll's includen?
2. Zo ja, hoe gaat dit in zijn gang? (Lijkt me niet dat de webserver ineens weet waar <project>.<lib> ineens vandaan kan komen?, of worden die DLL's geregistreerd?)
3. Kan ik met compiled ASP.NET code wel in de DLL's via de COM of DOTNET class?
4. Valt deze constructie aan te raden?
5. Zo niet, waarom niet?

Uiteraard hoef ik geen concrete antwoorden op de vragen, ik hoop er wel achter te komen hoe dit in zijn werk gaat doormiddel van materiaal (wat ik tot nu toe niet heb kunnen vinden) op het internet of uiteraard in boeken. Mocht een modje vinden dat ik te lui ben met zoeken... mijn excuses, maar ik kan (zie Gevonden materiaal) maar zeer weinig vinden of dit echt mogelijk is.

Overigens ben ik totaal geen .net / COM held, vandaar deze waarschijnlijk onnozele vragen.

[ Voor 7% gewijzigd door XiniX88 op 29-12-2009 14:46 ]

[marco_balk]

Kan je niet via Webservices alles aan elkaar koppelen?
Dat lijkt mij de meest voor de hand liggende oplossing.

[XiniX88]

Hoe zie je dat voor je?

PHP:

$word = new COM("word.application") or die("Unable to instantiate Word");
echo "Loaded Word, version {$word->Version}\n";

//bring it to front
$word->Visible = 1;

//open an empty document
$word->Documents->Add();

//do some weird stuff
$word->Selection->TypeText("This is a test...");
$word->Documents[1]->SaveAs("Useless test.doc");

Dit soort dingen moeten namelijk mogelijk zijn (dus gewoon het aanspreken van de onderstaande lagen)

Maar al zie je dit: http://nl3.php.net/manual/en/book.dotnet.php

"There are no user contributed notes for this page."

http://nl3.php.net/manual/en/book.com.php

Is wel wat uitgebreider, maar de vraag bij mij is meer, hoe ga ik ervoor zorgen dat dll's aanspreekbaar zijn of gaat dit automatisch.

Het PHP gebeuren dient alleen als weergave laag, de onderliggende extra dll's zal ik wel in ASP moeten programmeren, maar mij gaat het hoofdzakelijk om wat meer leesvoer over hoe en wat.

Misschien nog een domme vraag, maar kan Apache + PHP ook, of zorgt IIS voor de COM layer? Dit word mij alleen deels duidelijk uit:
http://nl3.php.net/manual/en/com.requirements.php

waarin staat dat PHP Windows wel COM aan kan, maar is dat in combi met IIS of maakt dat niet uit? Ik kan zelf wel Trial en Erroren, maar wil het wiel niet opnieuw uitvinden als het reeds is beschreven.

[ Voor 15% gewijzigd door XiniX88 op 29-12-2009 13:17 ]

[Kalentum]

Dat codevoorbeeld met Word dat je geeft zou gewoon moeten werken.

Het gebruik van de COM extension staat los van de webserver: command line zonder webserver zal het ook werken. COM dll's worden geregistreerd in Windows en niet in de webserver en de COM-extension van PHP weet hoe een dll gevonden en gebruikt kan worden. Dat gaat buiten Apache of IIS om. En een korte test met het codevoorbeeld op http://nl3.php.net/manual/en/class.dotnet.php zal aantonen dat het met .NET net zo werkt.

Ik ben vooral benieuwd waarom die weergavelaag in PHP zou moeten. Je schrijft niet in welke taal de bestaande ASP.NET code is geschreven maar ik zou zelf ervoor kiezen om aan te sluiten bij wat er al is.

[RedRose]

1. Kan ik zomaar via PHP .dll's includen?
2. Zo ja, hoe gaat dit in zijn gang? (Lijkt me niet dat de webserver ineens weet waar <project>.<lib> ineens vandaan kan komen?, of worden die DLL's geregistreerd?)
3. Kan ik met compiled ASP.NET code wel in de DLL's via de COM of DOTNET class?
4. Valt deze constructie aan te raden?
5. Zo niet, waarom niet?

1. en 2.) Nee dat gaat niet zomaar. Je moet een gecompileerde dll registreren in Windows Component Services. Je moet ook de juiste Activation / Launch permissions zetten in de DCOM en COM config properties. MS Word bijvoorbeeld moet geinstalleerd staan op de server als je het COM+ object Word.application wil kunnen aanspreken. Zoek maar eens op VB 6 register DLL COM+ configuration, dan vind je wel wat.

Communicatie gaat overigens via de PHP extensie php_com.dll. Die moet je dus aan hebben staan en in php.ini hebben geconfigureerd. Het maakt dus niet uit of je IIS of Apache gebruikt, zolang de user onder wie het PHP proces draait genoeg permissies heeft.

3) In principe kan je communiceren via COM+, maar aangezien .Net een GAC en Application Pools kent, is het _veel_ verstandiger om daar mee te werken. COM+ is een achterhaald model en erg lastig om te debuggen en te onderhouden. Ik zou alleen COM+ gebruiken als je oude VB 6 code hebt e.d.

4) / 5) Het hangt er nogal van af wat je wil doen. dat kan ik niet helemaal opmaken uit je vraag.

Overigens, COM+ icm PHP is niet echt aan te raden, vooral vanwege de foutgevoeligheid en performance load. Mocht je niet anders kunnen, dan wordt het toch een kwestie van trial en error, omdat de documentatie inderdaad nogal wazig en fragmentarisch is. Over COM+ an sich is op MSDN en op andere sites wel veel te vinden trouwens.

[XiniX88]

rutgerw schreef op dinsdag 29 december 2009 @ 13:48:
Dat codevoorbeeld met Word dat je geeft zou gewoon moeten werken.

Het gebruik van de COM extension staat los van de webserver: command line zonder webserver zal het ook werken. COM dll's worden geregistreerd in Windows en niet in de webserver en de COM-extension van PHP weet hoe een dll gevonden en gebruikt kan worden. Dat gaat buiten Apache of IIS om. En een korte test met het codevoorbeeld op http://nl3.php.net/manual/en/class.dotnet.php zal aantonen dat het met .NET net zo werkt.

Ik ben vooral benieuwd waarom die weergavelaag in PHP zou moeten. Je schrijft niet in welke taal de bestaande ASP.NET code is geschreven maar ik zou zelf ervoor kiezen om aan te sluiten bij wat er al is.

Mijn excuus, de huidige omgeving is ASP.NET, de webapplicatie die men nu heeft. De programmeertaal betreft VB.NET.

Echter moet de website zo licht mogelijk worden (de website wordt in gebieden opgevraagd waar de snelheid van het internet 56k bedraagd) en mede door ASP.NET, wordt er b.v. voor elke input de style appart meegegeven via de style tag, de history meegezonden in een JS gedeelte op de pagina, en is er een scala aan controls binnen ASP.NET dat onnodig veel of raar gebruik maakt van HTML.

Om deze reden heeft men besloten dat er meer controle moest zijn over hoe de HTML wordt gegenereerd, en dat kon aldus het bedrijf, via PHP + .NET.

Zelf heb ik me inderdaad nog niet verdiept of ASP.NET ook compleet gestript kan worden van al de overbodige informatie, en zelf PRECIES bepalen welke HTML er wordt gegenereerd. Mocht dit in ASP.NET wel mogelijk zijn, hoor ik het graag, maar de visie van ASP.NET is:

"ASP.NET maakt uitgebreid gebruik van zogenaamde controls. Pagina-onderdelen zoals labels, knoppen, keuzelijsten en tekstvakken zijn voorbeelden van controls. De ontwerper stelt een pagina samen door de juiste controls toe te voegen, en van elke control de eigenschappen in te stellen.
Controls bevatten de nodige programmacode om zelfstandig de juiste paginacode (in HTML-formaat) te produceren."

Vandaar de PHP variant. Maar als dat makkelijker gaat in een andere taal of ASP.NET, kan ik dit ook voorstellen, dit was echter hun voorstel, waarbij ik trachte te onderzoeken of dit haalbaar was.

Overigens zag ik net dat de performance ook laag zou zijn middels deze structuur, iets wat hierbij al helemaal niet de bedoeling moet zijn (gezien de grote aantallen data die worden verwerkt via de .NET programmatuur). Dan toch maar ASP.NET? Of is er een andere mogelijkheid om naar te kijken?

In ieder geval alvast dank voor de bovenstaande antwoorden En gelukkig werd mijn conclusie (info staat overal en nergens) bevestigd.

Btw, modje: titel van ASP.NET => .NET (het is alles behalve ASP gerelateerd, sorry voor de mixup!)

[ Voor 13% gewijzigd door XiniX88 op 29-12-2009 14:51 ]

[Janoz]

In dat geval zijn er eigenlijk twee mogelijkheden:
1 : Zorgen dat je ASP.NET applicatie kale html op gaat leveren (zal vast kunnen, maar hoe zou ik niet weten, ik werk er nooit mee)
2 : De door Marco Balk voorgestelde oplossing van webservices.

Aangezien ik me bij de 2e variant wat meer voor kan stellen zal ik die wat verder uitwerken. Zorg ervoor dat je je serv ice laag verserviced. Dat klinkt heel erg zweevie zweevie managment geblaat, maar wat het uiteindelijk betekend is dat je de functionaliteit van de huidige site gescheiden wordt van de daadwerkelijke presentatie. Op dat scheidingsvlak implementeer je vervolgens een berg webservices die de functionaliteit ontsluiten. Je php applicatie kan dan vervolgens redelijk simpel hier tegenaan gebouwd worden zonder dat er allemaal propriety of andere plakband dll hacks nodig zijn.

[XiniX88]

Ok SOAP + PHP lijkt me inderdaad een goede oplossing.

ASP.NET => SOAP <= PHP

Aannemende dat je doelt op een oplossing waarbij .NET een dergelijke SOAP creeerd die door PHP wordt opgehaald.

Echter, en misschien een rare reden, maar wat je nu doet is 2 keer een pagina parsen... 1 keer de soap, en PHP haalt dit weer op, en parsed deze informatie op haar beurt weer. Hierdoor kost 1 request intern ook 2 requests (HTTP).

Ik ken verder wel het MVC pattern, wat hier op lijkt... het Model scheiden (de ruwe informatie) van de View (presentatielaag), wat hierbij dus wordt gedaan, echter blijven deze handelingen wel binnen dezelfde taal. De Controller (acties die terug moeten worden gezonden) komt hierbij overigens ook mooi aan bode. Princiepe (waar ik nog niet over na had gedacht) is inderdaad leuk!

In het kort, waar ik mee zit is dat het ook 2 HTTP requests kost, 1 voor het klaarzetten van de SOAP en 1 voor het klaarzetten van de PHP, de eerste request wordt intern via HTTP protocol gedaan, de 2e is de presentatie voor de user.

Iemand die over deze laatste reden die me tegenhoud nog een licht kan schijnen? Ik kan in ieder geval al aardig ver komen met de zojuist gegeven antwoorden, waarvoor dank!

[ Voor 8% gewijzigd door XiniX88 op 29-12-2009 16:09 ]

[RedRose]

Als je dit alleen gaat doen om de html lichter te maken is SOAP natuurlijk overkill en onzinnig, evenals de veronderstelling zijn dat PHP 'lichtere' html oplevert dan ASP.net. ASP.Net kan zelf prima lichte html leveren, maar dan moet je er wel wat meer over nadenken, want out-of-the-box gaat dat idd niet.

Als dat echt de enige reden is, zou ik er geen SOAP laag tussen gooien en het dus gewoon in ASP.Net oplossen. Talk about ducttape oplossingen

Janoz zegt ook nadrukkelijk: "Aangezien ik me bij de 2e variant wat meer voor kan stellen zal ik die wat verder uitwerken." . Dat wil dus niet zeggen dat dat de beste manier is om het op te lossen.

[creator1988]

XiniX88 schreef op dinsdag 29 december 2009 @ 14:45:
[...]
Om deze reden heeft men besloten dat er meer controle moest zijn over hoe de HTML wordt gegenereerd, en dat kon aldus het bedrijf, via PHP + .NET.

WTF! ASP.NET kan prima elke nette html uitspugen die je wil.

[pedorus]

Als hierboven. Probeer maar eens:

quote: http://www.w3schools.com/aspnet/aspnet_pages.asp

HTML:

<html>
<body bgcolor="yellow">
<center>
<h2>Hello W3Schools!</h2>
<p><%Response.Write(now())%></p>
</center>
</body>
</html>

Je hoeft niet altijd controls te gebruiken, het zou mooi worden.

[XiniX88]

creator1988 schreef op dinsdag 29 december 2009 @ 17:13:
[...]


WTF! ASP.NET kan prima elke nette html uitspugen die je wil.

Kan ook wat rustiger. Zoals ik al zei ben ik geen ASP.NET programmeur, de 3 "programmeurs" die daar zitten werken met de native ASP.NET controls (zoals hierboven staat), en zagen zelf geen andere mogelijkheid.

Als je goed leest staat hierboven meerdere keren dat ik zelf niet weet of het in ASP.NET anders kan, maar dat ik de mogelijkheid met PHP wilde onderzoeken omdat het bedrijf daar zelf mee kwam (daarbij had ik wel de aanname gemaakt dat het in ASP moeilijker zou zijn ja).

Overigens een beetje een dubbel post, de persoon boven je zegt hetzelfde. Dus ga je moeder pesten ofzo.

RedRose schreef op dinsdag 29 december 2009 @ 16:30:
Als je dit alleen gaat doen om de html lichter te maken is SOAP natuurlijk overkill en onzinnig.

Dit gaf ik zelf ook al aan in mn post... Maar leuk dat je het even herhaald. Overigens als je de ASP.NET taal niet kent en je krijgt dingen als: http://www.w3schools.com/aspnet/aspnet_controls.asp dat te zien, snap je misschien waarom ik denk dat controls het enige is wat makkelijk gaat in ASP.NET.

Overigens vind ik het geen ducktape oplossing! Het is een laag tussen de data en het grafische. Een laag die je sowieso eigenlijk al zou moeten hebben zoals Janoz ook aangeeft. Wat je vervolgens gebruikt als front interface zou weinig uit moeten maken.

Er moet een front interface komen, hoe ik dat oplos maakt niet uit. Zelf ben ik meer een PHP iemand dan een ASP.NET iemand, valt wss ook wel op te maken uit bovenstaande . Dus de dingen SOAP aanbieden en er vervolgens meerdere soorten interfaces tegenaan zetten is niet eens zo'n gek idee.

pedorus schreef op dinsdag 29 december 2009 @ 18:00:
Als hierboven. Probeer maar eens:

[...]

Je hoeft niet altijd controls te gebruiken, het zou mooi worden.

Dankje, ik ga me wat meer in die hoek storten . Mijn aanname (wikipedia als bron) ging er vanuit dat gebruik van controls normaal was.

[ Voor 17% gewijzigd door XiniX88 op 30-12-2009 13:55 ]

[RedRose]

XiniX88 schreef op woensdag 30 december 2009 @ 13:51:
[...]

Dit gaf ik zelf ook al aan in mn post... Maar leuk dat je het even herhaald. Overigens als je de ASP.NET taal niet kent en je krijgt dingen als: http://www.w3schools.com/aspnet/aspnet_controls.asp dat te zien, snap je misschien waarom ik denk dat controls het enige is wat makkelijk gaat in ASP.NET.

Overigens vind ik het geen ducktape oplossing! Het is een laag tussen de data en het grafische. Een laag die je sowieso eigenlijk al zou moeten hebben zoals Janoz ook aangeeft. Wat je vervolgens gebruikt als front interface zou weinig uit moeten maken.

Er moet een front interface komen, hoe ik dat oplos maakt niet uit. Zelf ben ik meer een PHP iemand dan een ASP.NET iemand, valt wss ook wel op te maken uit bovenstaande . Dus de dingen SOAP aanbieden en er vervolgens meerdere soorten interfaces tegenaan zetten is niet eens zo'n gek idee.

Voel je niet aangevallen . Wat je jezelf af moet vragen is of het aanbrengen van een extra laag (in dit geval een SOAP service) echt nodig is. Heb je echt meerdere interfaces nodig? Of is het alleen voor 1 website? Is er sprake van dat veel externe systemen data via de service moet gaan ophalen? Moet het ophalen van de data wel echt compleet gescheiden worden van een interface, bijvoorbeeld omdat het transactionele data betreft, of misschien omdat je Ajax achtige dingen wil gaan doen?

Volgens mij moet je in ieder geval dingen zo simpel mogelijk houden. En als het 1 website betreft, met wat data uit databases, dan kan je dat gewoon prima integreren en ligt het manco natuurlijk bij de developers, voor wie het de taak is om volgens de requirements te programmeren. Als ze dat niet kunnen, moet je niet gelijk allerlei extra lagen gaan lopen toevoegen, maar juist de kern oplossen. Dan kan je later altijd extra services gaan toevoegen.

[Alex)]

Ik weet niet precies wat de website allemaal doet, maar door bijvoorbeeld de viewstate uit te schakelen (als je die toch niet gebruikt) kun je zo tientallen kilobytes besparen. Ook door een aantal ASP.NET (of nog erger: 3rd party) controls te vervangen door plain HTML-tags kun je al e.e.a. besparen.

[Grijze Vos]

Repeaters gebruiken voor je tabulaire data scheelt je waarschijnlijk al een bak aan ranzige html. Daarnaast kun je overwegen zelf control adapters te schrijven, maar dat is wel behoorlijk gecompliceerd, je neemt dan de verantwoordelijkheid voor het renderen van de html, de css, javascripts, en dat soort dingen. Daarnaast kun je ook nog eens de helft van de helperfuncties niet aanroepen zonder met reflectie te kutten.

[TheNameless]

Ik zou je aan raden om te gaan kijken of ASP.NET MVC misschien niet de juiste oplossing zou kunnen bieden.

Als ik het goed begrijp moet je bestaande .NET code gebruiken en zoveel mogelijk controle hebben over de gegenereerde HTML, hiervoor lijkt mij ASP.NET MVC uitermate geschikt.

Het zal wel een tijdje duren voor je het onder de knie hebt, maar als je nog helemaal geen ervaring hebt met ASP.NET, zal het ook wel weer meevallen denk ik.

[R4gnax]

TheNameless schreef op donderdag 31 december 2009 @ 13:49:
Ik zou je aan raden om te gaan kijken of ASP.NET MVC misschien niet de juiste oplossing zou kunnen bieden.

Als ik het goed begrijp moet je bestaande .NET code gebruiken en zoveel mogelijk controle hebben over de gegenereerde HTML, hiervoor lijkt mij ASP.NET MVC uitermate geschikt.

Het zal wel een tijdje duren voor je het onder de knie hebt, maar als je nog helemaal geen ervaring hebt met ASP.NET, zal het ook wel weer meevallen denk ik.

Dat inderdaad dus.

Losstaande views (en partial views) die netjes een geprepareerd view model afnemen dat via een strakke interface gedefinieerd is. Vervolgens kun je op het hoogste niveau van je view structuur een databind doen met je view model en dat naar beneden door laten sijpelen.

Je kunt dan in feite zo ongeveer alles behandelen als simpele 'substituteer string [[FOO]] hier' en 'geef sub-view model [[BAR]] door naar sub-view' met incidenteel een heel klein beetje presentatie logica waar nodig. Moet je werken met een IEnumerable of andere collecties, dan pluk je zoals Grijze Vos al zei de Repeater uit de kast, die zo ongeveer zo lichtgewicht is als maar zijn kan.

Daarnaast: vermijdt viewstate als de pest als je high performance wilt! (Maar dat is een gegeven wat je gelukkig al opgedrongen wordt als je MVC gebruikt.)

[XiniX88]

Zo erg aangevallen voel ik me niet, alleen van mensen als creator1988 kan ik misselijk worden (herhalen van wat andere zeggen, alleen maar om iemand aan te vallen).

Maar RedRose, het is niet zomaar het kleinste systeempje, geheel in details kan ik niet gaan maar wat er gaat komen is:

Bijhouden van competenties van mensen binnen een bedrijf. De applicatie bevat 180 tabellen en vele weergaves, dus het wordt niet zomaar een kleine applicatie. Ook komt er nog een mobiele versie (WinMo) reden dat dit niet online (dus via deze website) wordt gedaan is voor caching. Mobiele telefoons hebben daar vaak geen bereik (booreilanden), PC's kunnen wel uitstekend op internet, met de snelheid van 56kbit (aldus opdrachtgever). (internet versie is nodig omdat ze nu via VNC bij de app moeten, want database connectie is niet mogelijk vanaf extern, en VNC is te traag voor het internet onsite op een boorplatvorm).

Bijgehouden wordt onderandere:
- Welke certificeringen men heeft
- Wat men dan ook automatisch is (dus b.v. MCSA wat je automatisch hebt na 5 certificaten bij microsoft)
- Alle gegevens van de mensen
- inplannen van cursussen
- aanbieden van cursussen
- mensen die onder welke manager vallen

Dat dan in de meest uitgebreide vorm. Aangezien de mobiele applicatie ook data nodig heeft, zou dat ook via de SOAP kunnen, vandaar dat ik deze zeker wil gaan meenemen in mijn voorstel.

Een Mobiele client cached dus bijvoorbeel de gehele lijst van werknemers die vallen onder de betreffende manager, maar moet die lijst dus (when available) ook weer opvragen.

Het zou inderdaad mooier zijn al zou het in ASP.NET direct kunnen en dat ga ik dan ook zeker opzoeken, maar aangezien ik toch al delen om moet zetten zodat het XML/SOAP/JSON opvraagbaar moet zijn (bijvoorbeeld de vele grids, die dynamisch dienen te worden ingeladen) is de stap het te scheiden misschien ook wel een goede, vooral omdat het bedrijf verder wil in het aanbieden van online diensten, en de huidige applicatie overbodig wil laten worden.

Maar ik ga me in alle bovenstaande dingen verdiepen, ASP.NET MVC zal ik ook gaan bekijken, als ik het zo hoor is het al een opgezette structuur waarin je zelf je HTML kan bepalen In ieder geval allemaal bedankt voor het meedenken!

http://www.asp.net/learn/mvc/tutorial-21-cs.aspx << precies wat ik zocht netjes MVC (waarin ik met PHP al aardige ervaring heb opgedaan). Tnx!

Edit:
@grijzevos Ik had inderdaad al gekeken naar het zelf schrijven van controls, maar ik probeer een zo makkelijk mogelijke manier te vinden, dit zou inderdaad ook kunnen. Al je andere termen moet ik nog even gaan opzoeken op het grote internet (ik != ASP.NET programmeur)

@R4gnax Niet dat ik je compleet begrijp (een hoop van de termen zeggen mij niets) maar ik ga je bericht zeker ontcijferen (na het nieuwjaar )

[ Voor 14% gewijzigd door XiniX88 op 31-12-2009 15:39 ]

[R4gnax]

XiniX88 schreef op donderdag 31 december 2009 @ 15:19:
{snip}

Het zou inderdaad mooier zijn al zou het in ASP.NET direct kunnen en dat ga ik dan ook zeker opzoeken, maar aangezien ik toch al delen om moet zetten zodat het XML/SOAP/JSON opvraagbaar moet zijn (bijvoorbeeld de vele grids, die dynamisch dienen te worden ingeladen) is de stap het te scheiden misschien ook wel een goede, vooral omdat het bedrijf verder wil in het aanbieden van online diensten, en de huidige applicatie overbodig wil laten worden.

Alles wat hier boven staat kun je heel goed met asp.net direct doen en dat zou ik je ook heel erg aanraden. WCF web services schrijf je een maal en je kunt ze simpel weg via config files XML, SOAP en JSON endpoints geven om via te communiceren. Eerder genoemde MVC applications kunnen gebruikt worden om netjes models, views en controllers te scheiden. Pak daar nog Unity bij voor inversion of control en dependency injection en je kunt je hele applicatie super modulair maken.

Je webinterface kan dan daadwerkelijk echt een dunne schil worden.

Interop met PHP zou ik ten zeerste afraden. Dat wil namelijk zeggen dat je data én over appdomain boundaries, én over native processes heen moet gaan marshallen. Dat is heel, heel langzaam, zelfs vergeleken met reflection. De meest in de praktijk gebruikte stukken van reflection: run time type analysis, dynamic instancing en dynamic invokation, zijn niet eens zo langzaam. De mythe dat reflection zo langzaam zou zijn komt van de oude methodes om runtime zelf nieuwe classes te definiëren, maar sinds .NET 2.0 is daar fikse verbetering in gekomen.

Ook wel lachen is het feit dat het marshallen van data over application boundaries al een gedeelte van bovenstaande reflection operaties gebruikt. Dus zeggen dat COM-interop naar PHP sneller zou zijn dan ASP.NET omdat daar reflection gebruikt wordt, slaat als een tang op een varken. Als de andere programmeurs waar je naar refereerde claimen dat dit soort applicaties niet goed met asp.net zou kunnen, en dat als argument aanvoeren dan weten ze totaal niet waarover ze het hebben.

Misschien dat het feit dat de huidige applicatie in VB.NET geschreven is daar dan boekdelen spreekt: het zijn toch toevallig niet ex-VB6 programmeurs die wat homegrown asp.net zooi in elkaar hebben ge-kitbashed, of wel?