[ASP.NET] BLL met referenties naar HttpContext, is dat juist

[Verwijderd]

Gegeven een web applicatie in ASP.NET, met een DAL bestaande uit strongly typed dataset (m.b.v. Visual Studio's dataset designer) en een BLL. De BLL past regels/logica toe waarvoor informatie over de huidige gebruiker nodig is. Deze informatie is terug te vinden in sessie variabelen, via de User eigenschap van een Page en met behulp van de zgn. Roles klasse uit System.Web.Security

Dit zijn allemaal objecten die vanuit een ASPX pagina makkelijk te gebruiken zijn. Maar is het niet zo dat een BLL hier niets van zou moeten weten? Het lijkt mij dat een klasse in de BLL geen referentie zou moeten hebben naar System.Web om via de HttpContext toegang te krijgen tot een sessie variabele.

Maar dat zou betekenen dat alle methodes in de BLL voorzien moeten worden van extra parameters om toch de waarden in die variabelen te krijgen en er iets mee te doen. Of zie ik een elegante oplossing over het hoofd?

Om de verwarring compleet te maken: Op asp.net is een starterkit te vinden genaamd The BeerHouse. De programmeur heeft ook een boek geschreven over deze applicatie (ASP.NET 2.0 Website Programming, Problem - Design - Solution). In die applicatie erft iedere BLL klasse van een basis klasse die velden heeft voor de gebruiker en het IP adres. Hier wordt dus zonder probleem de BLL voorzien van eigenschappen die gekoppeld zijn aan de implementatie van de GUI.

Samengevat: Hoe lossen we het probleem op dat de BLL informatie nodig heeft om logica toe te passen, terwijl die informatie opgeslagen is op een wijze die specifiek is voor de implementatie van de GUI laag boven de BLL?

[whoami]

Je business logic zou in principe idd niets moeten weten van je infrastructuur. Je zou je BL classes kunnen 'injecteren' met de gegevens die nodig zijn, zoals je al zegt;
Niets weerhoudt je om je BL classes te laten afleiden van een base-class die die nodige members heeft, en zorg er gewoon voor dat bij het instantieren van je objecten, die properties gezet worden (zei het via constructor, zei het via properties).
Daarom zou je een soort factory kunnen gebruiken die je objecten instantieert, en de nodige velden hun waarde geeft.
Je kan imho hier het abstract factory pattern voor gebruiken waarbij je verschillende types factories kunt maken, aangezien die gegevens die je nodig hebt bij een WebApp van ergens anders zullen komen dan bij een Windows app bv.

Echter, als je zeker weet dat je applicatie altijd een web-app zal zijn, en je je BL nooit nodig zal hebben in een WinForms app oid, dan kan je er voor kiezen omwat pragmatischer te werk te gaan, en doen zoals je nu doet.... Al hou ik er zelf ook niet van om het zo te doen.

[Verwijderd]

Hey bedankt!

Ik weet 99% zeker dat er nooit een Windows Client zal komen. Maar ik weet ook 75% zeker dat er in de toekomst een WebService zal komen. Dat is natuurlijk wel een Web Client, net zoals de website. Maar ik weet niet zeker of webservices ook sessies kennen, en ook niet of de authenticatie bij de webservice (voor zover ik nu kan voorzien via SOAP headers) zal resulteren in dezelfde Identiteit en Rol/Groep klassen.

Dus de pragmatische oplossing (sowieso met base classes) heeft de voorkeur, maar ik heb net de baas verteld dat we extra tijd nodig hebben voor deze laag, zodat we later makkelijk de WebService kunnen toevoegen, dat moet dan wel kunnen.