A middle tier two-way talking control, thats what you can say about this datasource control. Suitable when you have a requirement of encapsulating your buisness logic in object, hence we say this control supports three tier architecture by providing a way to bind your presentation layer and data tier.
The ObjectDataSource control exposes a TypeName property that specifies an object type (class name) to instantiate for performing data operations. You can bind this control to a DAL (data access layer) or BLL (business logic layer) depending on requirement. More secured and organised is to BLL, thus return data will be stateless.
Nice tutorial for begineers is here : http://quickstart.developerfusion.co.uk/QuickStart/aspnet/doc/ctrlref/data/objectdatasource.aspx
Tuesday, July 3, 2007
Monday, July 2, 2007
Smart ways to add your database connection
Now a small question, where will you add the connection string for your project?
Simple question, right. There are multiple options here, you may place this in your code, config file, etc. Lets explore this in detail.
Its a bad idea to store connection strings in your pages for different reasons.
1. Bad practice from security point of view. In theory, no one should ever be able to view the source code of your ASP.NET pages. In practice, however, hackers have discovered security flaws in the ASP.NET framework. To sleep better at night, you should store your connection strings in a separate file.
2. Difficult managing change requests. Adding a connection string to every page makes it difficult to manage a website. If you ever need to change your password, then you need to change every page that contains it. If, on the other hand, you store the connection string in one file, you can update the password by modifying the single file.
3. Performance, connection pooling which is auto done by ADO.NET checks character by character and strings in multiple places will hence affect performance.
So strings in configuration files is our option here.Now that is a smart option, and an even more smart option if you need multiple application to access the same conneciton string is to place the same in the root config file (C:\WINDOWS\Microsoft.NET\Framework\[version]\CONFIG folder)
Having said that, lets just try to make this a bit more secure by encrypting the connection string. You may use aspnet_regiis to encrypt your config file as below
aspnet_regiis -pef connectionStrings ""
-pef (Protect Encrypt Filepath)
Simple question, right. There are multiple options here, you may place this in your code, config file, etc. Lets explore this in detail.
Its a bad idea to store connection strings in your pages for different reasons.
1. Bad practice from security point of view. In theory, no one should ever be able to view the source code of your ASP.NET pages. In practice, however, hackers have discovered security flaws in the ASP.NET framework. To sleep better at night, you should store your connection strings in a separate file.
2. Difficult managing change requests. Adding a connection string to every page makes it difficult to manage a website. If you ever need to change your password, then you need to change every page that contains it. If, on the other hand, you store the connection string in one file, you can update the password by modifying the single file.
3. Performance, connection pooling which is auto done by ADO.NET checks character by character and strings in multiple places will hence affect performance.
So strings in configuration files is our option here.Now that is a smart option, and an even more smart option if you need multiple application to access the same conneciton string is to place the same in the root config file (C:\WINDOWS\Microsoft.NET\Framework\[version]\CONFIG folder)
Having said that, lets just try to make this a bit more secure by encrypting the connection string. You may use aspnet_regiis to encrypt your config file as below
aspnet_regiis -pef connectionStrings "
-pef (Protect Encrypt Filepath)
Subscribe to:
Posts (Atom)