There are a couple of important changes that should be made to a couple of DAL classes in order that they can't be directly manipulated from the UI layer (in my case, it's undesirable to allow this). the chages are required in the following places (code to be changed in red, new code in blue:

1. DAL/SiteProvider.cs

here you have a set of declarations like the one below:

namespace MB.TheBeerHouse.DAL
{
public static class SiteProvider
{
     public static nameProvider Name
     {
         get { return nameProvider.Instance; }
     }
.. other stuff omitted

all references to the public static nameProvider should be changed to:

namespace MB.TheBeerHouse.DAL
{
public static class SiteProvider
{
     internal static nameProvider Name
     {
         get { return nameProvider.Instance; }
     }
.. other stuff omitted

2. DAL/nameProvider.cs

here, you want to change:

namespace MB.TheBeerHouse.DAL
{
    public abstract class nameProvider : DataAccess
    {
        private static readonly nameProvider _instance =
            (nameProvider)Activator.CreateInstance(
                Type.GetType(Globals.Settings.ProviderName.ProviderType));

        static nameProvider()
        {
        }

        static public nameProvider Instance
        {
            get
            {
                return _instance;
            }
        }
.. other stuff omitted

to:

namespace MB.TheBeerHouse.DAL
{
    public abstract class nameProvider : DataAccess
    {
        private static readonly nameProvider _instance =
            (nameProvider)Activator.CreateInstance(
                Type.GetType(Globals.Settings.Name.ProviderType));

        static nameProvider()
        {
        }

        static internal nameProvider Instance
        {
            get
            {
                return _instance;
            }
        }
.. other stuff omitted

This effectively means that only other code in App_Code (i.e. in our case the DAL and BLL classes) can use these classes which in turn means that none of the database access methods are available via the DAL to the UI.

further tweaks could be applied on the same basis to make the whole DAL namespace all but invisible to the UI, however, for my purposes, this is good enough (for now)... tho the more observant among you will no doubt be itching to change the SqlClient files in the same way (i.e. public class SqlNameProvider : NameProvider changed to internal class SqlNameProvider : NameProvider)


happy hacking :)

[edit] - if anyone knows of a way to mark the entire DAL section in a single stmt as internal (without breaking it away as a seperate dll), that would be a very 'cool' approach.


jimi

http://www.originaltalent.com

__________________
jimi

http://www.originaltalent.com

also worth noting (for anyone embarking on either of the two concurrent linqtosql projects on here at the moment) that the dbml files can be marked as either public or internal. the correct answer of course (based on the header article above) is to select internal!!

just as an aside.

[edit] i have 'noticed' that changing the dbml file to internal still shows the entity table names on traversing the DAL.LinqToSql.Articles class structure. not sure if there's a bug in the implementation or not. i'd 'hope' that by setting to internal that none of the poroperties would be visible to client apps outside of the app_code folder. this means that the database table names are in full view of any developer using your dll. this can't be a good thing as by marking as internal, i'd want those tables names to 'dissapear'. it can of course be 'frigged' by going into the dbml file and marking the table accessors as internal but i thought that this would have happened automatically by setting to internal. thoughts welcome.

jimi

http://www.originaltalent.com