[.net] Java-app aan .net enterprise apps.. tips?

[Alarmnummer]

Voor een opdracht ga ik aan de slag met .net en ik ben van huis uit een Java programmeur. Ik heb wel wat ervaring met het opbouwen van enterprise applicaties en ben erg geinteresseerd in een goeie structuur. Mijn vraag is in hoeverre ik mijn denken om moet gaan zetten. Zijn er bv good practices in Java die bad zijn op het .net platform? (Of andersom). Zijn er bepaalde dingen waar ik rekening mee moet houden?

Ga je een layering bv in .NET netzo opzetten als in Java? Bij java hoor ik veel: domain objects en DAO`s.. maar bij .NET zie ik weer allerlei andere kreten voorbij komen. Dus in hoeverre is het een vertaling van kreten... en in hoeverre zijn er echt fundamentele verschillen?

Dus mensen die ervaring hebben met Java en .NET (en niet prutsen).. graag commentaar/advies.

[ Voor 8% gewijzigd door Alarmnummer op 30-11-2004 20:03 ]

[Macros]

offtopic:
overloper

[Verwijderd]

Hangt er een beetje vanaf wat je met Java gedaan hebt en wat je met .Net gaat doen.

Zowel Java (J2ME, J2SE en J2EE) als .NET zijn geschikt voor heel veel verschillende toepassingen. Een simpel antwoord is er dan ook niet. Iemand die JSP code schrijft en overstapt op .NET websites zal met andere zaken te maken krijgen als iemand die met EJBs werkte of iemand die aan mobiele toepassingen werkt.

[Alarmnummer]

Verwijderd schreef op dinsdag 30 november 2004 @ 20:13:
Hangt er een beetje vanaf wat je met Java gedaan hebt en wat je met .Net gaat doen.

Enterprise -> Enterprise.. Dus geen verschil in het 'soort' applicatie.

Ik wil dus weten hoe de kretologie zich laat vertalen... en of er ook fundamentele verschillen zijn waar je rekening mee moet houden. Het gaat me dus ook niet om details... of wat beter/slechter is. Ik wil weten waar ik als Java programmeur rekening mee moet houden.. en waar niet..

[ Voor 39% gewijzigd door Alarmnummer op 30-11-2004 20:20 ]

[MSalters]

Mijn ervaring met DAO's is dat het een typisch pattern is voor mensen die overengineeren. De meeste "enterprise" applicaties zijn niet voor enterprises. Als je drie databases met acht versies hebt, OK. Rule of Thumb: als je nadenkt over MySQL is een DAO overkill.

[Woy]

Een van de grote verschillen tussen Java en .NET vind ik hoe je met events om gaat. Bij Java heb je daar allemaal handler classes voor en bij .NET heb je daar Delegates voor ( Op zich kan je dat nog steeds redelijk gelijk behandelen ).

Nou heb ik juist niet zoveel ervaring met Java in enterprise omgevingen aangezien ik er alleen een beetje op school mee heb leren programmeren en op mijn stages vooral met .NET en C++ bezig ben geweest. Dus ik kan over de verschillen ook niet echt veel zeggen in het echte enterprise gebeuren.

Voor de rest vind ik .NET ieder geval redelijk op Java lijken qau ontwerpen. Alleen in .NET maak je assemblies, maar volgens mij is een JAR file in Java precies hetzelfde.

[blender]

1 woord: SOAP

[whoami]

blender schreef op dinsdag 30 november 2004 @ 23:52:
1 woord: SOAP

Soap is een protocol dat zowel in .NET als in Java kan gebruikt worden.

--

In veel .NET tutorials / voorbeelden / artikelen zie je dat ze werken met DataSets, maar ik ben daar toch zo geen voorstander van; althans niet voor in enterprise applicaties met complexe businesslogica.
DataSets zijn wel een makkelijke oplossing als je gewoon wat data wilt tonen op een form (web of windows) de user de mogelijkheid heeft om deze data aan te passen en ze dan opnieuw te gaan persisten. Echter, eens je wat complexere BL hebt, dan stuit je snel op de beperkingen.

Mocht je een Windows applicatie bouwen, dan zou je er voor kunnen kiezen om je BLL via webservices of .NET remoting (Java: RMI ?) beschikbaar te gaan stellen. Als je voor .NET remoting kiest, kan je je objecten in IIS hosten, wat het makkelijkst is (je maakt dan gebruik van de IIS security etc...).
Echter, aangezien je een webapplicatie gaat bouwen kan je - denk ik - je BL wel op dezelfde machine zetten als je webserver, en dan heb je geen remoting of webservices nodig (en dus ook geen soap).
Ik zou een DAL maken en een BL die je dan in je webpages gebruikt.
Je kan ook eens kijken naar het CSLA.NET framework dat ontworpen is door Rockford Lothka (boek: Expert C# Business Objects).

[Verwijderd]

.NET verplicht je wel beter om na te denken over je ontwerp. Waar je in Java alles mocht overriden (tenzij het sealed was) is dat in .NET niet zo. Daar ben je echt aangewezen op methods die virtual zijn

[Woy]

Als je een webpage gaat bouwen is denk het grootste vershil ASP.NET. Dat zit compleet anders in elkaar als JSP. ASP.NET is gebouwd om zo veel mogelijk op Windows forms te lijken. Zo wordt er onder andere standaard een ViewState meegestuurd. Het is slim om van te voren na te denken over hoe je hier gebruik van wilt maken. In een aantal gevallen kan het handiger zijn om de ViewState uit te schakelen.

Voor de rest werkt ASP.NET ook met een event systeem. Voor zover ik weet is dat in JSP minder het geval.

[Alarmnummer]

MSalters schreef op dinsdag 30 november 2004 @ 23:46:
Mijn ervaring met DAO's is dat het een typisch pattern is voor mensen die overengineeren. De meeste "enterprise" applicaties zijn niet voor enterprises. Als je drie databases met acht versies hebt, OK. Rule of Thumb: als je nadenkt over MySQL is een DAO overkill.

Wat is dat voor onzin. Ik denk dat je eens een cursus enterprise applicaties schrijven moet gaan volgen. Je verzand al redelijk snel in allerlei nare problematiek.. en als je je aspecten niet gaat scheiden dan kom je onheroepelijk in de problemen. Je krijgt een dikke klont van onbegrijpelijke code. Prak je de gui layer er ook nog bij in trouwens??

Om het nog maar even complexer te maken.. boven mijn 'core' domain layer hang ik zelfs nog een service layer die niets anders doet dan de transacties coordineren en objecten opzoeken.

[ Voor 26% gewijzigd door Alarmnummer op 01-12-2004 09:19 ]

[Alarmnummer]

blender schreef op dinsdag 30 november 2004 @ 23:52:
1 woord: SOAP

SAOP is niet nodig aangezien er geen remote communicatie plaats vind. (Enterprise->Enterprise was wel wat misleidend, maar ik doelde ermee op het feit dat ik gewoonlijk met java enterprise applicaties bezig bent... en dit keer met een .NET)

[Tuxie]

Om even kort te zijn: grote verschillen aangaande gebruikte patterns e.d. zijn er niet. En je hebt het goed gezien, het is vooral het verschil in terminologie dat op hetzelfde neerkomt als je er goed over nadenkt. .NET aanhangers praten altijd over 'safe code' en 'assemblies' die door de JIT compiler gecompileerd wordt. In mijn optiek doet de JAVA compiler hetzelfde alleen heten de files en de compilers net even anders. Revolutionair is het allerzins.

Zelf vind ik JAVA wat cleaner als je net begint, wil je in Visual Studio een leuk project maken met eigen componenten en veel grafische zooi verhuizen waar VS dat initieel neerzet, dan ben je altijd eerst uren bezig met slopen. Maargoed da's persoonlijk. De taal C# is een afgeleide van JAVA en C++, alhoewel ik het meer op JAVA vind lijken dan op C++. De datasets waaraan gerefeerd wordt is een sterk punt in VS, alhoewel het allereerst onwennig kan overkomen.

Alles heeft zijn voor en tegens, maar mijn ervaring is dat als je een serieuze enterprise applicatie bouwt het geen fuck uitmaakt of je het nu in JAVA of in .NET doet, simpelweg omdat de IDE's altijd toegespitst zijn op het snelle 'sleur en pleur' werk. Bouw je een applicatie met patterns, domein, business en presentatie layers dan zul je in beide omgevingen evenveel tijd kwijt zijn.

[EfBe]

Wat zijn de eisen? Bij Java zit enterprise logica dat je nodig hebt veelal in de app server, zoals cross-app transaction functionaliteit. Bij .NET niet, daar zit dat in COM+ en via EnterpriseServices beschikbaar voor jou. Het is dus van het grootste belang dat men hier weet wat de eisen zijn, zodat men wel/niet kan adviseren om enterprise services te gaan gebruiken, remoting of webservices of gewoon een webapp bv. Je vraag an sich is veel te vaag.

[Verwijderd]

Verwijderd schreef op woensdag 01 december 2004 @ 08:46:
.NET verplicht je wel beter om na te denken over je ontwerp. Waar je in Java alles mocht overriden (tenzij het sealed was) is dat in .NET niet zo. Daar ben je echt aangewezen op methods die virtual zijn

Nou, dat is niet zo, je kan een niet-virtuele method nog steeds overriden met het keyword "new" in de te overridden method. (C#)

[Woy]

door het new keyword te gebruiken wordt een methode toch niet virtual geoverridden? Of heb ik dat nou verkeerd?

heb het even getest en dan wordt de methode dus niet virtual overschreven. Dan heb je er in de meeste gevallen nog steeds niks aan dus.

[ Voor 39% gewijzigd door Woy op 01-12-2004 11:26 ]

[whoami]

Verwijderd schreef op woensdag 01 december 2004 @ 11:16:
[...]


Nou, dat is niet zo, je kan een niet-virtuele method nog steeds overriden met het keyword "new" in de te overridden method. (C#)

Daarmee override je geen method maar 'hide' je gewoon de reeds bestaande method.

[Alarmnummer]

EfBe schreef op woensdag 01 december 2004 @ 11:10:
Wat zijn de eisen? Bij Java zit enterprise logica dat je nodig hebt veelal in de app server, zoals cross-app transaction functionaliteit. Bij .NET niet, daar zit dat in COM+ en via EnterpriseServices beschikbaar voor jou. Het is dus van het grootste belang dat men hier weet wat de eisen zijn, zodat men wel/niet kan adviseren om enterprise services te gaan gebruiken, remoting of webservices of gewoon een webapp bv. Je vraag an sich is veel te vaag.

Het is gewoon een 'standaard' webapplicatie met standaard crud functionaliteit en wat zoekwerk. Daar komt het in grote lijnen op neer. Dus geen webservices, geen distributed applicatie/remoting.. een 'eenvoudige' webapplicatie dus.

[EfBe]

Alarmnummer schreef op woensdag 01 december 2004 @ 12:11:
[...]

Het is gewoon een 'standaard' webapplicatie met standaard crud functionaliteit en wat zoekwerk. Daar komt het in grote lijnen op neer. Dus geen webservices, geen distributed applicatie/remoting.. een 'eenvoudige' webapplicatie dus.

Dan is het woord 'enterprise' dus niet echt van toepassing. M.a.w.: transactions louter op de database, gecontrolleerd in de layer op je DAL, en verder is je logica voornl. in dienst van het pompen van data van GUI naar DB en vice versa.

[Alarmnummer]

EfBe schreef op woensdag 01 december 2004 @ 12:34:
[...]
Dan is het woord 'enterprise' dus niet echt van toepassing. M.a.w.: transactions louter op de database, gecontrolleerd in de layer op je DAL, en verder is je logica voornl. in dienst van het pompen van data van GUI naar DB en vice versa.

Om het helemaal leuk te maken.. we gebruiken jouw llblgen pro.

[Infinitive]

Als de applicatie niet zo ingewikkeld is, niet zo ingewikkeld zal worden en vooral snel in elkaar gezet moet worden, dan zou ik de neiging hebben om dat product van EfBe te gebruiken en de code direct in de webservices te plakken. Misschien dat je van bepaalde onderdelen wat losse componenten wilt maken, maar als het voornamelijk data van GUI naar DB pompen is, dan is een aparte laag voor BL wat overkill lijkt me. Maar goed daar kan je het beste zelf over oordelen.

In zo'n situatie zal unit testing wel lastig zijn, maar in zo'n geval lijken me functional tests op webservice niveau toch al voldoende (met misschien wat unit tests voor specifieke componenten).

(uhm ja, lazy infinitive heeft ooit wel eens zitten expertimenteren met EfBe's spul)

[ Voor 5% gewijzigd door Infinitive op 01-12-2004 14:23 ]

[Alarmnummer]

Ik heb een aantal vragen:
-Het moet bijvoorbeeld mogelijk zijn om nieuws toe te voegen aan de site (titel en inhoud). Voor java zou ik dan een DAO`s entities aanmaken/genereren en alle functionaliteit centraal via een NieuwsService aanbieden. In de nieuwsservice bepaald ik ook hoe de transacties verlopen.

Is het in .net gebruikelijk om het ook op deze manier te doen? Is het verstandig om bv hier mijn transacties aan te sturen? En hoe goed laat dit zich vertalen met LLBGEN Pro?

In java heb je bv een Servlet en je kan ervoor kiezen om 1 instantie hiervan aan te maken die doro meerdere threads worden gebruikt. De servlet kan ik bv een referentie geven naar een volledig geconfigureerde NiewsManager en dan is het kwestie om de webcalls naar die NieuwsManager te vertalen (meestal met een van de 10.000 weblayertools).

Wordt voor ASP.NET ook 1 zo`n object aangemaakt die calls van clients uiteindelijk bij een object laat aankomen? Of word voor ieder request een nieuw object aangemaakt?

[tijn]

Alarmnummer schreef op woensdag 01 december 2004 @ 18:43:
Ik heb een aantal vragen:
-Het moet bijvoorbeeld mogelijk zijn om nieuws toe te voegen aan de site (titel en inhoud). Voor java zou ik dan een DAO`s entities aanmaken/genereren en alle functionaliteit centraal via een NieuwsService aanbieden. In de nieuwsservice bepaald ik ook hoe de transacties verlopen.
Is het in .net gebruikelijk om het ook op deze manier te doen? Is het verstandig om bv hier mijn transacties aan te sturen? En hoe goed laat dit zich vertalen met LLBGEN Pro?

In .NET doe ik het precies op dezelfde wijze. Gaat prima. Als je het vertaalt naar een situatie waar je LLBLGen Pro gebruikt krijg je dat je de DAO's laat genereren door LLBLGen Pro en vanuit de Service laag je dingen ermee gaat doen.
In theorie zou je voor simpele apps de service laag ook weg kunnen laten en alles vanuit de ASP.NET code-behind kunnen doen, maar je loopt dan wel het risico dat je veel code in je UI krijgt die daar eigenlijk niet thuishoort. Ook als je later bijvoorbeeld je nieuws ook als RSS wilt aanbieden is een zo'n service laag behoorlijk handig. Let wel, we hebben het hier niet over een webservice he?

In java heb je bv een Servlet en je kan ervoor kiezen om 1 instantie hiervan aan te maken die doro meerdere threads worden gebruikt. De servlet kan ik bv een referentie geven naar een volledig geconfigureerde NiewsManager en dan is het kwestie om de webcalls naar die NieuwsManager te vertalen (meestal met een van de 10.000 weblayertools).

Wordt voor ASP.NET ook 1 zo`n object aangemaakt die calls van clients uiteindelijk bij een object laat aankomen? Of word voor ieder request een nieuw object aangemaakt?

ASP.NET werkt met page-events. Deze kunnen zowel in de .aspx pagina zitten als in de code-behind (als je VS.NET gebruikt). Zie het als een soort van front-controller (een vrij karige, dat wel). Gewoonlijk maak je (nou ja, ik ) in een page event zoals Load of Init een instance aan van de service (eventueel gedecoreerd met wat security dingen) die je dan gedurende de page-lifecycle gebruikt wordt.
Veel java mensen geven nogal eens af op dit model omdat hiermee geen stricte MVC mogelijk is. Persoonlijk vind ik het een beetje flauwekul. Het is een oplossing waar best goed mee te werken valt en die heus geen spaghetti code en koppeling van logica en UI in de hand werkt.

[Alarmnummer]

En hoe zit het met vinden/aanmaken van objecten? Je kunt gewoon een XXXService aanmaken en die later weer laten gc`en? Ik vind het met java erugh praktisch om van een Service object maar 1 aan te maken die helemaal geconfigureerd is met alles wat die nodig heeft (oa dao`s). Hoe kan ik dat het beste aanpakken? Is er een manier om objecten terug te vinden (afgezien van Singletons)?

[TlighT]

tijn schreef op woensdag 01 december 2004 @ 19:31:
ASP.NET werkt met page-events. Deze kunnen zowel in de .aspx pagina zitten als in de code-behind (als je VS.NET gebruikt). Zie het als een soort van front-controller (een vrij karige, dat wel). Gewoonlijk maak je (nou ja, ik ) in een page event zoals Load of Init een instance aan van de service (eventueel gedecoreerd met wat security dingen) die je dan gedurende de page-lifecycle gebruikt wordt.

Een standaard aspx pagina is geen front controller maar een page controller. Het zijn ook geen single instances zoals servlets wel zijn. Je kunt wel een front controller maken in asp.net maar dan moet je werken met een custom httphandler.

Het boek "Enterprise Solution Patterns Using Microsoft .NET" is van MSDN te downloaden, daarin worden dit soort dingen uitgelegd.

Maverick.NET is een MVC framework voor asp.net dat werkt met een front controller, meer zoals je dat in Java gewend bent.

[The - DDD]

Wat in standaar web apps in .NET vaak het geval is, is dat resultsets helemaal totaan de code behind wordt doorgetrokken. Er lastig om je content van je backend te splitsen dan.

En is het een kwestie van een andere taal, een andere API. En als je echt wat wil, net zo ingewikkeld als iets in Java bouwen (dit is niet goed of slecht).

Verder de MSDN moet je mee leren omgaan. Net zoals je met Javadoc moet leren omgaan. Verschil is dat de MSDN een stuk uitgebreider is en soms een beetje vaag in elkaar hangt.

Verder is het gewoon een kwestie van bitjes schuiven...

[tijn]

TlighT schreef op woensdag 01 december 2004 @ 20:53:
[...]

Een standaard aspx pagina is geen front controller maar een page controller. Het zijn ook geen single instances zoals servlets wel zijn. Je kunt wel een front controller maken in asp.net maar dan moet je werken met een custom httphandler.

ah natuurlijk!

*moet minder blaten over theorie waar hij te weinig verstand van heeft*

[riezebosch]

Ik heb zelf dit boek van C#, en op de website staat een gratis appendix voor verschillende soorten programmeurs (en zo dus ook voor Java programmeurs).

Misschien kan je er wat mee?

[tijn]

Alarmnummer schreef op woensdag 01 december 2004 @ 20:33:
En hoe zit het met vinden/aanmaken van objecten? Je kunt gewoon een XXXService aanmaken en die later weer laten gc`en? Ik vind het met java erugh praktisch om van een Service object maar 1 aan te maken die helemaal geconfigureerd is met alles wat die nodig heeft (oa dao`s). Hoe kan ik dat het beste aanpakken? Is er een manier om objecten terug te vinden (afgezien van Singletons)?

Het is gangbaar om bij een webapplicatie (dat wordt het toch?) het hele spul aan te maken en te laten GC-en bij elk request. Indien je LLBLGen gebruikt laat je die vanuit de service de objecten voor je aanmaken. Dat lijkt me gewoon het eenvoudigst. Wellicht kan efbe je nog wel wat tips geven hieromtrent.

[EfBe]

Alarmnummer schreef op woensdag 01 december 2004 @ 18:43:
Ik heb een aantal vragen:
-Het moet bijvoorbeeld mogelijk zijn om nieuws toe te voegen aan de site (titel en inhoud). Voor java zou ik dan een DAO`s entities aanmaken/genereren en alle functionaliteit centraal via een NieuwsService aanbieden. In de nieuwsservice bepaald ik ook hoe de transacties verlopen.

Is het in .net gebruikelijk om het ook op deze manier te doen? Is het verstandig om bv hier mijn transacties aan te sturen? En hoe goed laat dit zich vertalen met LLBGEN Pro?

We ondersteunen 2 paradigma's: selfservicing (entity.Save() etc..) en adapter (adapter.SaveEntity(entity) etc..). Indien je via een service wilt gaan werken is het verstandig adapter te gebruiken. Je entities zijn dan de data holders waar je mee werkt in de applicatie en de persistence logic zit in de service waar je middels een DataAccessAdapter instance de entities fetched, saved en delete.

Je hebt 2 soorten transacties: de database transacties en de application transacties. De database transacties houden in dat je in een routine een aantal acties uitvoert en die moeten als geheel een atomic transaction vormen, en indien 1 faalt moeten ze allemaal terugrollen. De application transaction houdt in dat je COM+ (enterprise services) gebruikt om transacties te laten lopen over meerdere applicaties/appdomains/threads/objects, wellicht ook database acties. In jouw geval lijkt me dat laatste niet zo zinvol, tenzij je het moeilijk wil maken natuurlijk COM+ transacties zijn in een handomdraai te gebruiken.

MOcht je via een service willen werken, wel remoting gebruiken.

Alarmnummer schreef op woensdag 01 december 2004 @ 20:33:
En hoe zit het met vinden/aanmaken van objecten? Je kunt gewoon een XXXService aanmaken en die later weer laten gc`en? Ik vind het met java erugh praktisch om van een Service object maar 1 aan te maken die helemaal geconfigureerd is met alles wat die nodig heeft (oa dao`s). Hoe kan ik dat het beste aanpakken? Is er een manier om objecten terug te vinden (afgezien van Singletons)?

Je zit veel te stateful te denken, krijg ik het idee. Een webrequest is een stateless aangelegenheid, want zodra de page is gerendered is alles weg (op de session en de algehele application state na dan).

Ik zou je willen vragen of je een wat globale functionele overview zou kunnen geven, want dat lijkt me verstandiger dan meteen in detailistische code-oplossingen te gaan denken. Als voor een wat simpelere website men toch een algehele service gaat opzetten krijg ik in het algemeen toch het idee dat men wat aan het over-engineeren is ipv werkelijk het probleem aan het oplossen is

[ Voor 25% gewijzigd door EfBe op 02-12-2004 09:45 ]

[whoami]

EfBe schreef op donderdag 02 december 2004 @ 09:41:
[...]

MOcht je via een service willen werken, wel remoting gebruiken.

Ik zou eerder het omgekeerde zeggen: als je via remoting (of webservices) wilt werken, zul je dat 'adapter' patroon moeten gebruiken.
(Of bedoelde je dat niet ? )

[EfBe]

whoami schreef op donderdag 02 december 2004 @ 09:44:
[...]
Ik zou eerder het omgekeerde zeggen: als je via remoting (of webservices) wilt werken, zul je dat 'adapter' patroon moeten gebruiken.
(Of bedoelde je dat niet ? )

Allebei Met die laatste zin vooral dat remoting efficienter is in dit geval, daar er puur .NET gebruikt wordt.

[Alarmnummer]

EfBe schreef op donderdag 02 december 2004 @ 09:41:
Indien je via een service wilt gaan werken is het verstandig adapter te gebruiken.

Dat had ik al uitgevonden.

Je hebt 2 soorten transacties: de database transacties en de application transacties. De database transacties houden in dat je in een routine een aantal acties uitvoert en die moeten als geheel een atomic transaction vormen, en indien 1 faalt moeten ze allemaal terugrollen.

Ik ben alleen database transacties nodig omdat er geen shared state is.

Je zit veel te stateful te denken, krijg ik het idee. Een webrequest is een stateless aangelegenheid, want zodra de page is gerendered is alles weg (op de session en de algehele application state na dan).

Afhankelijk van het soort applicatie zijn mijn Service objecten statefull of stateless. Maar ook Stateless Service objecten maak ik bij het opstarten van de applicatie eenmalig goed aan (en hebben dan beschikking over alle DAO`s en goodies die ze nodig zijn). De stateless Service objecten houden verder zelf (uiteraard) geen state bij als ze gebruikt worden tijdens de requests.

ls voor een wat simpelere website men toch een algehele service gaat opzetten krijg ik in het algemeen toch het idee dat men wat aan het over-engineeren is ipv werkelijk het probleem aan het oplossen is

Hoezo? Een Service object is toch een mooi punt om bv de transacties aan te sturen en centraal logica te managen?? Het alternatief is dat de ASP pagina`s dus gaan bepalen hoe dit moet gaan verlopen.. en dat lijkt mij niet echt wenselijk. Of sla ik de plank mis?

[ Voor 6% gewijzigd door Alarmnummer op 02-12-2004 10:49 ]

[tijn]

Alarmnummer schreef op donderdag 02 december 2004 @ 10:45:
Hoezo? Een Service object is toch een mooi punt om bv de transacties aan te sturen en centraal logica te managen?? Het alternatief is dat de ASP pagina`s dus gaan bepalen hoe dit moet gaan verlopen.. en dat lijkt mij niet echt wenselijk. Of sla ik de plank mis?

Nee hoor, de spijker op zijn kop, maar voor .NET begrippen neigt dit al naar over-engineering .

[EfBe]

tijn schreef op donderdag 02 december 2004 @ 10:57:
[...]

Nee hoor, de spijker op zijn kop, maar voor .NET begrippen neigt dit al naar over-engineering .

hehe

Ik denk dat het een miscommunicatie is mbt termen. In de MS wereld praat je in tiers, en stop je de logica die alarmnummer in een 'service' will stoppen in een 'Business logic tier', een class library die dingen regelt voor de GUI en dingen controlleert dus. De GUI kan niks, called alleen de middle tier methods en die regelen bv transacties of calls naar andere tier objects.

[TlighT]

Maar dus als je een stateless service hebt voor je bl-transacties, dan heb je imho de keuze tussen:

- de service een singleton maken en deze te gebruiken in je aspx pagina's met als performance nadeel dat voor elke concurrent request een nieuwe thread wordt gebruikt uit de threadpool, terwijl dat misschien niet nodig is.
- gebruik maken van een (single instance) httphandler, met denk ik als nadeel dat je een hoop standaard asp.net functionaliteit (server controls, databinding, events, etc.) niet meer goed kunt gebruiken.

Het laatste heb ik ook nooit gedaan en neigt wellicht (vanuit .net perspectief gezien) naar overengineering.

[oh,when?]

Een van de meer interesante verschillen tussen J2EE en Enterprise .NET is het volgende:

"...but perhaps more important than the underlying mechanisms is general support for the pattern language, as it is philosophically different from Java.

A Java enterprise developer, if he adheres to patterns and best practices
for his platform, typically tackles a problem by sketching a domain model
based on the requirements, breaking that domain model into sequences and
class hierarchies (this is called the dominant decomposition), and then
dealing with issues such as security, distribution, and persistence as
aspects of that domain model. A .NET developer, on the other hand, typically
tackles the same sort of problem by sketching a data model rather than a
domain model first, and creating hierarchies of data objects rather than
domain objects. Rather than creating a pure OO model to which O/R tools,
CMP, Hibernate, DAO's, Data Transfer Objects, etc. can be applied, the
typical .NET developer composes a data model to which objects, xml,
relational data, documents, etc. can be applied. It may seem a subtle
difference, or it may seem impure in OO terms to Java patterns purists, but
one of its strengths is that it is by and large a simple and extremely
flexible way of managing data across tiers. .NET has no CMP equivalent per
se, and escapes debates about JDO vs. EJB vs. Hibernate by simply making
data objects a top-level first class design element rather than an aspect of
a domain model.

I'm not espousing one approach over the other, merely pointing out that
there are architectural differences in the way data is typically managed on
the two platforms..."

Dit is een quote van Sean Neville, JCP Executive Committee representative voor Macromedia, EJB 2.0/J2EE 1.4 expert group member en Flash Remoting for J2EE/.NET architect bij Macromedia in een discussie over de architectuur verschillen tussen de J2EE en .NET variant. Ik meen me een discussie gelezen te hebben die gedeeltelijk hierover ging op EfBe's blog, maar kan hem zo snel niet vinden. Footnote, ik ben geen J2EE of .NET expert, kan dan zelf ook weinig inbrengen.

HTH

[Alarmnummer]

Ik ben niet geinteresseerd in een discussie .NET vs Java btw. Ik doe dit project in .NET en ik wil weten hoe taalonafhankelijk mijn kennis is.

[The - DDD]

Alarmnummer schreef op donderdag 02 december 2004 @ 17:29:
Ik ben niet geinteresseerd in een discussie .NET vs Java btw. Ik doe dit project in .NET en ik wil weten hoe taalonafhankelijk mijn kennis is.

Verrader...

Mijn idee, een goede Java engineer zal goed uit de voeten kunnen met .NET. Je zult wel verbaasd op kijken van het relatief geringe gebruik van patterns en OO engineering. Omgekeerd is de overstap een stuk lastiger. Een ,NET-er zal gelijk iets vergelijkbaars willen als de oude vertrouwde DataSet... (Of was 't ResultSet )

(Deze informatie heb ik uit eerste hand van een docent van mijn werkgever die cursussen op beide vlakken geeft.)

Geen zorgen maken dus, en gewoon goed je help files en overige documentatie (boeken, PDF's) lezen en het moet prima lukken.

[ Voor 5% gewijzigd door The - DDD op 02-12-2004 19:19 ]

[oh,when?]

Alarmnummer schreef op donderdag 02 december 2004 @ 17:29:
Ik ben niet geinteresseerd in een discussie .NET vs Java btw. Ik doe dit project in .NET en ik wil weten hoe taalonafhankelijk mijn kennis is.

Mijn reply is geen .NET vs Java verhaal, het is simpelweg een antwoord op je openingspost:

"...en in hoeverre zijn er echt fundamentele verschillen?

[Alarmnummer]

oh,when? schreef op donderdag 02 december 2004 @ 20:02:
[...]
Mijn reply is geen .NET vs Java verhaal, het is simpelweg een antwoord op je openingspost:
[...]

Ok.. het was ook een beetje preventief bedoelt aangezien veel topics verzanden in discussies en ik wil gewoon een praktisch antwoord op mijn vraag(en).

[alienfruit]

Ik gebruik vaak RemObjects SDK 3.0 voor al me remoting meuk in .NET, en dan nog liefst in combinatie met Chrome Zie ook een link hieronder, om te zien hoe makkelijk het is

http://www.remobjects.com...4-45BA-BFB4-7823A0290579}

[whoami]

oh,when? schreef op donderdag 02 december 2004 @ 17:13:
Een van de meer interesante verschillen tussen J2EE en Enterprise .NET is het volgende:

[...]


Dit is een quote van Sean Neville, JCP Executive Committee representative voor Macromedia, EJB 2.0/J2EE 1.4 expert group member en Flash Remoting for J2EE/.NET architect bij Macromedia in een discussie over de architectuur verschillen tussen de J2EE en .NET variant. Ik meen me een discussie gelezen te hebben die gedeeltelijk hierover ging op EfBe's blog, maar kan hem zo snel niet vinden. Footnote, ik ben geen J2EE of .NET expert, kan dan zelf ook weinig inbrengen.

HTH

Dit is wel waar; als .NET developer zal je meer geneigd zijn, of meer 'gezogen' worden naar het gebruik van DataSets enzo een meer 'data oriented' approach gaan nemen.
Echter, het project waar ik nu aan werk, is een n-tier project en maakt ook gebruik van DataSets etc.... Echter, hebben we al een aantal -ik ga niet zeggen tekortkomingen of nadelen- 'issues' ondervonden waaruit blijkt dat DataSets niet altijd zo goed zijn; niemand houd je tegen om in .NET een domain model te gaan gebruiken, maar het is wel zo dat de meeste 'best practices' die je vind op internet wel die approach gebruiken. MS propageert deze methode ook het meest, maar moesten ik het huidige project waar ik aan werk herbeginnen, dan zouden we het anders aanpakken.