Prohibit access to data layer

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
Thu May 01 10:04:04 CDT 2008


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.com/Blog/cns!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
Thu May 01 11:38:17 CDT 2008

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.com/Blog/cns!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
Thu May 01 13:06:21 CDT 2008


Assembly.GetExecutingAssembly().
Assembly.GetCallingAssembly Method


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



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.com/Blog/cns!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
Thu May 01 13:11:34 CDT 2008

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.getcallingassembly.aspx
>
>
>
> 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.com/Blog/cns!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
Thu May 01 16:12:58 CDT 2008

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
Mon May 05 06:59:03 CDT 2008

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/0tke9fxk.aspx


Chris.

sloan
Mon May 05 09:06:43 CDT 2008


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/0tke9fxk.aspx
>
>
> Chris.

Alvin
Mon May 05 11:17:04 CDT 2008

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/0tke9fxk.aspx
>>
>>
>> Chris.
>
>