[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

Prohibit access to data layer

milop

5/1/2008 11:11:00 AM

Hello.

We have an app with UI, Business, and Data Tiers.

How can we ensure that the DAL tier is accessed only from the BLL tier? The
idea is to prevent direct access to the DAL from the UI (asp.net pages in
our case).

Thanks in advance,

Mike


8 Answers

sloan

5/1/2008 3:04:00 PM

0


Well, this is one reason I put the layers into different assemblies.

So that the Presentation layers .... do NOT reference the DAL(assembly), and
thus you can't break the rules.

Are you asking because of security? Or because of just enforcing good
design.

If its just good design, break the code out into different assemblies.

And if someone adds a reference from the Pres to the DAL.dll, fire them.

...

See:
http://sholliday.spaces.live.co...!A68482B9628A842A!139.entry

Also look at the "bird's eye view" article I mention at that blog entry.





"milop" <milop@slomins.com> wrote in message
news:%23%23ns%23v3qIHA.4912@TK2MSFTNGP03.phx.gbl...
> Hello.
>
> We have an app with UI, Business, and Data Tiers.
>
> How can we ensure that the DAL tier is accessed only from the BLL tier?
> The idea is to prevent direct access to the DAL from the UI (asp.net pages
> in our case).
>
> Thanks in advance,
>
> Mike
>


milop

5/1/2008 4:38:00 PM

0

Thanks for replying.

Yes, it's in its own assembly.

Aside from firing the person I was wondering if there was a way, in the DAL
code, to detect the "caller".


> "sloan" <sloan@ipass.net> wrote in message
> news:evVSjw5qIHA.2064@TK2MSFTNGP05.phx.gbl...
>>
>> Well, this is one reason I put the layers into different assemblies.
>>
>> So that the Presentation layers .... do NOT reference the DAL(assembly),
>> and thus you can't break the rules.
>>
>> Are you asking because of security? Or because of just enforcing good
>> design.
>>
>> If its just good design, break the code out into different assemblies.
>>
>> And if someone adds a reference from the Pres to the DAL.dll, fire them.
>>
>> ..
>>
>> See:
>> http://sholliday.spaces.live.co...!A68482B9628A842A!139.entry
>>
>> Also look at the "bird's eye view" article I mention at that blog entry.
>>
>>
>>
>>
>>
>> "milop" <milop@slomins.com> wrote in message
>> news:%23%23ns%23v3qIHA.4912@TK2MSFTNGP03.phx.gbl...
>>> Hello.
>>>
>>> We have an app with UI, Business, and Data Tiers.
>>>
>>> How can we ensure that the DAL tier is accessed only from the BLL tier?
>>> The idea is to prevent direct access to the DAL from the UI (asp.net
>>> pages in our case).
>>>
>>> Thanks in advance,
>>>
>>> Mike
>>>
>>

sloan

5/1/2008 6:06:00 PM

0


Assembly.GetExecutingAssembly().
Assembly.GetCallingAssembly Method


http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getcallingass...



You can play around with those...I don't know if they'll work, but its at
least a hint.


The best solution is to put together a standards document and make people
stick to it.
It takes at least 1 person with some authority in the organization to get it
to work.
If you have a bunch of knights at the round table, then FIRING (at least)
one of them is the best route.
I'm half joking and half serious.

...

Good luck.





"milop" <milop@slomins.com> wrote in message
news:%2320Zkn6qIHA.1436@TK2MSFTNGP05.phx.gbl...
> Thanks for replying.
>
> Yes, it's in its own assembly.
>
> Aside from firing the person I was wondering if there was a way, in the
> DAL code, to detect the "caller".
>
>
>> "sloan" <sloan@ipass.net> wrote in message
>> news:evVSjw5qIHA.2064@TK2MSFTNGP05.phx.gbl...
>>>
>>> Well, this is one reason I put the layers into different assemblies.
>>>
>>> So that the Presentation layers .... do NOT reference the DAL(assembly),
>>> and thus you can't break the rules.
>>>
>>> Are you asking because of security? Or because of just enforcing good
>>> design.
>>>
>>> If its just good design, break the code out into different assemblies.
>>>
>>> And if someone adds a reference from the Pres to the DAL.dll, fire them.
>>>
>>> ..
>>>
>>> See:
>>> http://sholliday.spaces.live.co...!A68482B9628A842A!139.entry
>>>
>>> Also look at the "bird's eye view" article I mention at that blog entry.
>>>
>>>
>>>
>>>
>>>
>>> "milop" <milop@slomins.com> wrote in message
>>> news:%23%23ns%23v3qIHA.4912@TK2MSFTNGP03.phx.gbl...
>>>> Hello.
>>>>
>>>> We have an app with UI, Business, and Data Tiers.
>>>>
>>>> How can we ensure that the DAL tier is accessed only from the BLL tier?
>>>> The idea is to prevent direct access to the DAL from the UI (asp.net
>>>> pages in our case).
>>>>
>>>> Thanks in advance,
>>>>
>>>> Mike
>>>>
>>>
>


milop

5/1/2008 6:12:00 PM

0

I figured you were half-serious.

I thought about looking at the call stack but your way looks cleaner. I'll
take a closer look at it.

Thanks again,

Mike

"sloan" <sloan@ipass.net> wrote in message
news:uFqEYW7qIHA.5096@TK2MSFTNGP02.phx.gbl...
>
> Assembly.GetExecutingAssembly().
> Assembly.GetCallingAssembly Method
>
>
> http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getcallingass...
>
>
>
> You can play around with those...I don't know if they'll work, but its at
> least a hint.
>
>
> The best solution is to put together a standards document and make people
> stick to it.
> It takes at least 1 person with some authority in the organization to get
> it to work.
> If you have a bunch of knights at the round table, then FIRING (at least)
> one of them is the best route.
> I'm half joking and half serious.
>
> ..
>
> Good luck.
>
>
>
>
>
> "milop" <milop@slomins.com> wrote in message
> news:%2320Zkn6qIHA.1436@TK2MSFTNGP05.phx.gbl...
>> Thanks for replying.
>>
>> Yes, it's in its own assembly.
>>
>> Aside from firing the person I was wondering if there was a way, in the
>> DAL code, to detect the "caller".
>>
>>
>>> "sloan" <sloan@ipass.net> wrote in message
>>> news:evVSjw5qIHA.2064@TK2MSFTNGP05.phx.gbl...
>>>>
>>>> Well, this is one reason I put the layers into different assemblies.
>>>>
>>>> So that the Presentation layers .... do NOT reference the
>>>> DAL(assembly), and thus you can't break the rules.
>>>>
>>>> Are you asking because of security? Or because of just enforcing good
>>>> design.
>>>>
>>>> If its just good design, break the code out into different assemblies.
>>>>
>>>> And if someone adds a reference from the Pres to the DAL.dll, fire
>>>> them.
>>>>
>>>> ..
>>>>
>>>> See:
>>>> http://sholliday.spaces.live.co...!A68482B9628A842A!139.entry
>>>>
>>>> Also look at the "bird's eye view" article I mention at that blog
>>>> entry.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> "milop" <milop@slomins.com> wrote in message
>>>> news:%23%23ns%23v3qIHA.4912@TK2MSFTNGP03.phx.gbl...
>>>>> Hello.
>>>>>
>>>>> We have an app with UI, Business, and Data Tiers.
>>>>>
>>>>> How can we ensure that the DAL tier is accessed only from the BLL
>>>>> tier? The idea is to prevent direct access to the DAL from the UI
>>>>> (asp.net pages in our case).
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Mike
>>>>>
>>>>
>>
>
>


Mike Urquiola

5/1/2008 9:13:00 PM

0

Couldn't you put the business and DAL together and mark the DAL as internal?
Then only the business could create and use DAL objects.


"milop" <milop@slomins.com> wrote in message
news:%23%23ns%23v3qIHA.4912@TK2MSFTNGP03.phx.gbl...
> Hello.
>
> We have an app with UI, Business, and Data Tiers.
>
> How can we ensure that the DAL tier is accessed only from the BLL tier?
> The idea is to prevent direct access to the DAL from the UI (asp.net pages
> in our case).
>
> Thanks in advance,
>
> Mike
>


Chris Shepherd

5/5/2008 11:59:00 AM

0

Mike Urquiola wrote:
> Couldn't you put the business and DAL together and mark the DAL as internal?
> Then only the business could create and use DAL objects.

By that token, why not mark the DAL methods as internal and use the
InternalsVisibleToAttribute to indicate that the BLL has permission to see the
DAL's internal methods?

http://msdn.microsoft.com/en-us/library/0tk...


Chris.

sloan

5/5/2008 2:07:00 PM

0


Those are pretty good ideas, given the OP's needs.




"Chris Shepherd" <chsh@nospam.chsh.ca> wrote in message
news:ecvi7eqrIHA.1952@TK2MSFTNGP05.phx.gbl...
> Mike Urquiola wrote:
>> Couldn't you put the business and DAL together and mark the DAL as
>> internal? Then only the business could create and use DAL objects.
>
> By that token, why not mark the DAL methods as internal and use the
> InternalsVisibleToAttribute to indicate that the BLL has permission to see
> the DAL's internal methods?
>
> http://msdn.microsoft.com/en-us/library/0tk...
>
>
> Chris.


Alvin Bruney [ASP.NET MVP]

5/5/2008 4:17:00 PM

0

I agree, very good idea.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------


"sloan" <sloan@ipass.net> wrote in message
news:#tFdH0rrIHA.5068@TK2MSFTNGP02.phx.gbl...
>
> Those are pretty good ideas, given the OP's needs.
>
>
>
>
> "Chris Shepherd" <chsh@nospam.chsh.ca> wrote in message
> news:ecvi7eqrIHA.1952@TK2MSFTNGP05.phx.gbl...
>> Mike Urquiola wrote:
>>> Couldn't you put the business and DAL together and mark the DAL as
>>> internal? Then only the business could create and use DAL objects.
>>
>> By that token, why not mark the DAL methods as internal and use the
>> InternalsVisibleToAttribute to indicate that the BLL has permission to
>> see the DAL's internal methods?
>>
>> http://msdn.microsoft.com/en-us/library/0tk...
>>
>>
>> Chris.
>
>