Wrox Programmer Forums
|
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old May 16th, 2008, 07:46 AM
Friend of Wrox
 
Join Date: Mar 2007
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts
Default Important changes to DAL

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
 
Old May 16th, 2008, 10:26 AM
Friend of Wrox
 
Join Date: Mar 2007
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts
Default

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





Similar Threads
Thread Thread Starter Forum Replies Last Post
BLL and DAL kss BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 13 November 24th, 2008 03:59 PM
Help with BLL and DAL kss BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 0 November 20th, 2008 09:23 PM
DAL to BLL rodmcleay LINQ 3 June 2nd, 2008 12:15 PM
Important need help... riki_gill ASP.NET 1.x and 2.0 Application Design 0 October 25th, 2006 09:19 AM
DAL 'stuff' pithhelmet VB Databases Basics 0 November 10th, 2004 04:42 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.