[ASP.NET] Project dependencies

[Verwijderd]

Voorbeeld:

Een solution bestaat uit meerdere projecten.

Project_1 = framework met DAL klasse etc. (een applicatie in IIS)
Project_2 = module
Project_3 = module

Project_2 en project_3 zijn gekoppeld aan project_1 via de project reference.
Dit heb ik gedaan om het Session, Application object te sharen over verschillende ASP.NET projecten.
In project_1 kunnen de namespaces, etc uit project_2 en project_3 gebruikt worden. Logisch.

Maar ik kan geen project-reference naar project_1 aanbrengen ivm 'circular dependency'.

Vraag:

Nu wil ik in project_2 en project_3 gebruik maken van bijvoorbeeld de DAL klasse uit project_1.

Op welke manier zou ik nu wel de DAL-klasse uit project_1 kunnen aanspreken?

Als dit niet kan wat is dan de beste oplossing?

1. Plaatsen van de DAL en andere lagen in een apart project (dll).
2. De dll van project_1 koppelen via de .NET reference aan project_2 en project_3.

Of misschien een andere mogelijkheid?

[whoami]

Als je in project2 en project3 je DAL classes uit project1 wilt gebruiken, dan moet je in project2 en 3 een referentie opnemen naar project 1.

In project1 een reference opnemen naar project2 en 3 is bagger. Je wilt nl. dat je framework onafhankelijk van andere projecten kunnen werken.
Je bouwt projecten die gebruik maken van het framework, en niet omgekeerd.

In je framework die referenties leggen omdat je zou gebruik kunnen maken van die Session en Application state is een zware designfout. Je framework moet onafhankelijk kunnen werken, en moet bv. ook kunnen werken in WinForm apps.

[Verwijderd]

whoami schreef op 22 October 2003 @ 14:23:
Als je in project2 en project3 je DAL classes uit project1 wilt gebruiken, dan moet je in project2 en 3 een referentie opnemen naar project 1.

In project1 een reference opnemen naar project2 en 3 is bagger. Je wilt nl. dat je framework onafhankelijk van andere projecten kunnen werken.
Je bouwt projecten die gebruik maken van het framework, en niet omgekeerd.

In je framework die referenties leggen omdat je zou gebruik kunnen maken van die Session en Application state is een zware designfout. Je framework moet onafhankelijk kunnen werken, en moet bv. ook kunnen werken in WinForm apps.

Ik geef je helemaal gelijk dat het een designfout is. Maar ik zoek hier dus ook een oplossing voor.

Maar hoe leg ik de link dat ik toch vooral mijn user-identity behoud waarmee ik op het framework heb ingelogd?

Zo het in het topic is omschreven werkt het wel. Dan heb ik alle projecten op 1 user-context. Maar het is zeker geen lekkere manier.

Hoe pak je dit dan het beste aan?

[whoami]

Geef je user-identy door aan de framework classes of methods.

[Verwijderd]

Okay dat is duidelijk.

Project_1 is de IIS-applicatie.
De onderliggende projecten in deze applicatie de modules die gebruik maken van het framework.

Alleen nu krijg in project_2 in de bin directory project_1.dll en project_2.dll.
Dat is juist.
In de framework applicatie krijg ik alleen project_1.dll.

Als ik de applicatie start dan krijg ik een fout zo snel ik dus een aspx-bestand uit project_2 aanroep. Dit komt omdat deze de dll niet kan vinden die dus niet in de bovenliggende directory aanwezig is.

Volgens mij kan je de build-dir niet aanpassen naar bovenliggend.

Hoe compileer ik de dll's uit onderliggende projecten wel naar project_1\bin?

[whoami]

Je framework mag nooit functie-calls gaan doen naar je applicaties die dat framework gebruiken.
Je framework mag niets afweten van applicaties die dat framework gebruiken, het zijn de applicaties die dat framework gebruiken die calls doen naar het framework, en niet omgekeerd.

[Verwijderd]

whoami schreef op 22 October 2003 @ 16:25:
Je framework mag nooit functie-calls gaan doen naar je applicaties die dat framework gebruiken.
Je framework mag niets afweten van applicaties die dat framework gebruiken, het zijn de applicaties die dat framework gebruiken die calls doen naar het framework, en niet omgekeerd.

Okay het framework weet nergens wat van af.

Er van uitgaande dat ik 1 applicatie in IIS heb, dacht ik dat ik een project ging maken waar het inloggedeelte etc in werd opgevangen.

In deze directory worden de andere modules (projecten) ontwikkeld als sub-dirs.
Op deze manier krijg ik dus dat de dll's niet in de juiste dir komen te staan.

Is dit een juiste denkwijze of moet ik totaal anders denken?
Zoja zou je kort willen aangeven hoe je het zou doen.

[whoami]

Wat bedoel je met 'de dll's komen niet in de juiste subdir te staan'?

Als je in .NET een reference legt naar een ander project (dll), dan wordt die dll naar je bin-folder van je huidige applicatie gekopieerd.
Dit gebeurt om versie-conflicten met dll's te voorkomen. (Dll hell).

[Verwijderd]

whoami schreef op 22 October 2003 @ 16:40:
Wat bedoel je met 'de dll's komen niet in de juiste subdir te staan'?

Als je in .NET een reference legt naar een ander project (dll), dan wordt die dll naar je bin-folder van je huidige applicatie gekopieerd.
Dit gebeurt om versie-conflicten met dll's te voorkomen. (Dll hell).

Ik heb dus een IIS-applicatie project_1 met in de root een \bin met daarin de dll.
In de root maak ik dan ook de andere modules (projecten) aan. Deze krijgen een eigen \bin directory met daarin de dll uit project_1 en de eigen dll.

Ik wil dus dat de dll's uit de overige modules (projecten) naar de \bin van project_1 gaan.

Ik hoop dat het duidelijk is.

[whoami]

Verwijderd schreef op 22 oktober 2003 @ 16:44:
[...]


Ik heb dus een IIS-applicatie project_1 met in de root een \bin met daarin de dll.
In de root maak ik dan ook de andere modules (projecten) aan. Deze krijgen een eigen \bin directory met daarin de dll uit project_1 en de eigen dll.

Ik wil dus dat de dll's uit de overige modules (projecten) naar de \bin van project_1 gaan.

Ik hoop dat het duidelijk is.

Als je in project 1 een reference maakt naar die andere projecten, dan wordt die dll van dat andere project toch naar de bin directory van project 1 gekopieerd?

[Verwijderd]

whoami schreef op 22 October 2003 @ 19:31:

[...]


Als je in project 1 een reference maakt naar die andere projecten, dan wordt die dll van dat andere project toch naar de bin directory van project 1 gekopieerd?

Okay volgens mij denken we verschillend over de definitie 'framework'.
Hierom ben ik enorm aan het stuntelen gekomen met de dependencies en het gebruik hiervan.

Wat ik uit bovenstaand antwoord opmerk is dat jij met het framework bedoeld de klassen als bijvoorbeeld het DAL, etc.
Dat is mij duidelijk.

Mijn opvatting over 'framework' was op dat moment: "Het raamwerk waar de modules in draaien" en dus niet jouw definitie. Dat staat bij mij ook apart in een dll.

In project_1 worden references aangebracht naar de andere projecten.
Vanuit die projecten word met bijvoorbeeld het DAL, etc gecommuniceerd.
Dit kan natuurlijk ook met project_1.

Duidelijk! Bedankt! Het werd voor mij duister toen er verwarring begon te ontstaan.

[gorgi_19]

Op een of andere manier moet ik bij dit alles heel erg denken aan een Plugin pattern van Fowler, icm het dynamisch laden van assembly's.

[Verwijderd]

gorgi_19 schreef op 22 oktober 2003 @ 21:21:
Op een of andere manier moet ik bij dit alles heel erg denken aan een Plugin pattern van Fowler, icm het dynamisch laden van assembly's.

Misschien wel.
Als je nuttige links hebt graag!

kZal er zelf ook is naar gaan zoeken.

[gorgi_19]

Verwijderd schreef op 22 oktober 2003 @ 21:28:
[...]


Misschien wel.
Als je nuttige links hebt graag!

kZal er zelf ook is naar gaan zoeken.

Een begin is iig: http://www.martinfowler.com/eaaCatalog/plugin.html

Andere nuttige info:
Activator.CreateInstance()
[Assembly]
System.Reflection

[Verwijderd]

gorgi_19 schreef op 22 October 2003 @ 21:30:
[...]

Een begin is iig: http://www.martinfowler.com/eaaCatalog/plugin.html

Andere nuttige info:
Activator.CreateInstance()
[Assembly]
System.Reflection

Ja volgens mij heb je me eerder gewezen op reflection. Ik heb me er toen kort in verdiept. En heb er wat aan geroken. Ik ga er is mee aan de slag.

Kijken of Fowler voor mij de uitkomst is.

[Verwijderd]

gorgi_19 schreef op 22 October 2003 @ 21:21:
Op een of andere manier moet ik bij dit alles heel erg denken aan een Plugin pattern van Fowler, icm het dynamisch laden van assembly's.

Ik heb het een en ander opgezocht en gelezen over deze pattern.

Volgens mij kan het ook gewoon dmv project dependencies. Deze zijn dan gekoppeld met de hoofdapplicatie.

Graag hoor ik welke voordelen je ziet in het gebruik van de dll's om deze dynamisch te gaan laden in de applicatie?

[PhoneTech]

haltink,

volgens mij haal je een aantal dingen door elkaar.

Het is niet verstandig om applicaties dependant van elkaar te laten zijn.

Wat mij lijkt dat je moet doen, is de DAL en de functionaliteit die je wil delen met de andere projecten in een aparte klasse library hebben staan (project 4).

Vervolgens kan je project 1, 2 en 3 een reference naar project 4 laten maken, zodat ze allemaal van de zelfde logica gebruik kunnen maken.

Omdat je nu logica in project 1 hebt zitten wat eigenlijk een IIS applicatie hebt, heb je de dingen al niet goed gescheiden. Gewoon een extra klasse library maken.

Zou ook meteen je user identity in die klasse gebruiken (maak gebruik van System.Security.Principal.GenericIdentity)

[Verwijderd]

De structuur is als volgt:

Library met DAL en standaard klassen functionaliteit om te delen met de modules.
Module_1
Module_2
Module_3

De modules 1 2 en 3 zijn afzonderlijk ontwikkelde applicaties met een eigen virtual directory.
De library is ook afzonderlijk ontwikkeld.
De modules 1 2 en 3 hebben een reference naar de library.

Deze moeten in 1 IIS-applicatie worden ondergebracht.

In onderstaande link wordt hier een oplossing voor gegeven.

http://www.asp101.com/articles/jayram/sharestate/default.asp

Er is een nieuwe applicatie gemaakt waar de modules in worden geplaatst.

Graag jullie mening over deze aanpak.