asp.net user controls

[DJFuji]

All my presentation layer files (aspx.cs files) inherit from a presentation layer base class which handles pulling the connstring from web.config. Problem is when i have to create a usercontrol which needs SQL access. Since the user control inherits from system.web.ui.usercontrol, it can't grab connstring from the base class.

I work around this by manually instantiating an object from the base class and then grabbing the connString using the public "get" method. This seems cheesy though. Is there a recommended method to work around this? Obviously, i dont want to simply get rid of the base class.

 

[replicator]

I couple of questions.

Why are you storing your connection string in presentation components?

You should separate anything to do with the database and put it into a data access layer.

Logically, it is best practice to separate your work into 3 tiers.
1) presentation
2) business logic
3) data access.

each layer should only know how to communicate to the adjacent layer, so the presentation should not know or care about details such as the connection string.

I would leave the connection string in the web.config

e.g.
<configuration>
<appSettings>
<add key="ConnString"
value="server=localhost;uid=sa;pwd=;database=mydatabase" />
</appSettings>
</configuration>

and reference the connection string when required from the code that talks to your database

string connectionString = (string)ConfigurationSettings.AppSettings["ConnString"];

Different approaches to handling your data access, but you might want to look into a data persistence framework that handles this sort of thing for you. (nhibernate)

 

[torpid]

If I am reading it right, your pages are inherited from some base page class and you want to get some property of thise base page from a user control. Is that right?

If so what's the problem? You can just use the Page property of the user control and typecast it as the base page type then access the property you need.

In reality, though, you should not be utilizing the connection string in this manner. I strongly suggest you read the above advice and consider at least using something like the Data Access Application Block that is part of the Enterprise Library.

 

[DJFuji]

Hmmm....replicator, i actually am using the n-tier architecture with a presentation, biz, and DAL setup to interface with SQL Server. We keep the connection string in web.config but i guess i never questioned why we would pull it from presentation and pass through the tiers to the DAL instead of having DAL just pull it directly. It's just the way we've always done it, but now that you mention it, i'm asking around as to why we do that.

Torpid, assuming we access the connstring in the DAL, i still need access to my exception handling in the base class. Are you suggesting i cast the usercontrol as type baseclass and then use the base class methods as if i was inheriting directly? That doesn't cause problems since you're essentially inheriting from dual sources? (System.web.ui.usercontrol and baseclass)

 

[torpid]

Originally posted by: DJFuji
Hmmm....replicator, i actually am using the n-tier architecture with a presentation, biz, and DAL setup to interface with SQL Server. We keep the connection string in web.config but i guess i never questioned why we would pull it from presentation and pass through the tiers to the DAL instead of having DAL just pull it directly. It's just the way we've always done it, but now that you mention it, i'm asking around as to why we do that.

Torpid, assuming we access the connstring in the DAL, i still need access to my exception handling in the base class. Are you suggesting i cast the usercontrol as type baseclass and then use the base class methods as if i was inheriting directly? That doesn't cause problems since you're essentially inheriting from dual sources? (System.web.ui.usercontrol and baseclass)

I'm still unclear what you are doing and what the issue is. Which classes inherit from the base class? What does the base class do? Do your ASPX pages inherit from it, or only your User Controls, or do both need to?

Is your issue is that you have to inherit from user control and can't inherit from your base class, which provides some basic logic? What exactly is in this base class? Why can't it be an instantiated variable within the user conrol or a singleton object that you call from the user control? Can you elaborate on the design?

 

[DJFuji]

I talked to the guy who designed the architecture and he said that since connstring is stored in web.config, it should be pulled from the presentation layer and passed through the tiers. If the data layer was pulling the connstring from web.config it would technically be the DAL directly accessing the presentation layer.

Torpid, your assumptions are correct. I have base classes in each tier of my application (UI/BLL/DAL). In the Presentation layer the base class does exception handling and grabs connString from web.config. My aspx pages currently inherit from this base class but i need user controls to inherit from it as well since otherwise i have to use some cheesy workarounds (instantiate the base class and "get" the connString) to get the base class functionality out.

I've thought about creating a derived class of usercontrol by inherit from the system.web.ui.usercontrol and then putting base class functionality into it to make a sort of 'userctrl_base.cs" page which i could then inherit from my usercontrols, but that seems like an unnecessary duplication of code.

 

[torpid]

Ugh...

The guy who designed the architecture needs to learn how to design a better architecture. He has some seriously flawed reasoning. The presentation layer should not have any knowledge of the database connection string. Violating this tenet is a lot worse than invoking a .config file in the data layer, which itself is a seriously lazy approach, though not really all that bad. .config files exist for windows forms and web forms both, and as such are basically presentation-independant. What he is basically saying is that no tier other than the presentation tier can be configurable in any way unless the configuration parameters are passed FROM the presentation layer. This is a terrible notion and should be strongly discouraged.

For a better approach, I highly recommend pointing out the Enterprise Library to him and if you have the ability to do so, demand that he use the configuration block for storing these settings. Using the library (the DAAB) will also *eliminate* the need to pass around connection strings in the first place. And it will also greatly simplify your exception handling routines (EMAB).

As for the user controls, you should not be using inheritence in this way probably. Create these helper classes as singleton objects that you call from your user controls. These helper classes should be part of the architecture classes ideally but I wouldn't put much faith in the architecture guy being able to implement these properly.

 

[DJFuji]

Torpid,

The link you gave is broken. I will look into the singleton objects and enterprise library.

 

[torpid]

Link is fixed.

Singleton in c#

 

[replicator]

Originally posted by: DJFuji
I talked to the guy who designed the architecture and he said that since connstring is stored in web.config, it should be pulled from the presentation layer and passed through the tiers. If the data layer was pulling the connstring from web.config it would technically be the DAL directly accessing the presentation layer.

As Torpid pointed out, your architect is wrong to assume that the .config is a part of the presentation layer. It is used for storing configuration parameters, with the purpose of being able to make changes without recompiling, or in some cases, restarting the application.

Your presentation layer should be thin as possible, it sounds like there is too much responsibility in this layer for your application. The ideal goal of n-tier design is to be able to swap out any of the layers with something that has the same interface, and still have your application still functional.

 

[torpid]

Just a side note, if the objects don't need to get any external data but are just helper functions, you can probably do away with the notion of singleton and make them sealed or regular classes.