What are the issues related to the deployment of data access application?
Some of the basic issues related to the deployment of the data access applications are:
• Can we suppose the required database exists at the target location?
• If the database does exist then how can we get the connection string of it? Should we get it at the installation time? Or at the first run?
• If the database does not exist then how it can be created? Is it the responsibility of human installing our application? Or the application should create it at the time of installation?
• If the database is to be created by the application installation, then how does the installation setup know where (on which machine) to create the database? And what user name and password the setup should use to create the database?
• Once, the database is created or its connection string is found at the setup time, then how to store the connection string for later use (regular execution)?
What if the database address (connection string) is changed during the application life cycle then what should be the application behavior? How can the application be aware of the new connection string?
• If the database schema is hard-coded in the code (like table and field names) and the DB schema is changed (table/field name or data type is changed or new field/table added or some fields/tables deleted) because of any reason, then how to fix this problem?
You can see from the above points that the basic issue is the identification of the address (or connection string) of the database server. The most important point to remember here is that the application must perform in any condition and must not be crashed because of any condition and most of the problems (if not all) should be handled without any change in the code or any update patch installation
How do I solve the deployment issues ?
• The easiest and very sound solution is to provide the database script to create necessary database and tables along with the installation and ask your user to run the script on the target database server to create the required database. Then ask the user to supply the connection string at the installation setup time.
• You can create the database with the installation by executing the database creation script with the installation. But before this, you have to ask the user the location (the computer on the network) where the database server exists, and the user name, password to login to the database.
• The connection string should be stored in a text or binary or xml file. You can also encrypt the connection string before writing it to the file. The application, thus, is required to decrypt and load the connection string in the memory at each startup.
• The application should load the connection string at each startup and attempt to connect to the database. If the connection attempt fails then it should inform the user that the database is not available and ask the user to setup the database and try again. The application should also allow the user to change the database connection string any time and, it the application logic permits, let the user specify to work without database. If the user specifies a new connection string during the application startup or regular execution, the application should save it for later use.
• One solution to the schema changed problem is to use views and stored procedure wherever possible. But if this is not done or the change is too big to be catered by the views and/or stored procedure then you can supply a new data access module update (a new DLL may be). For this reason, it is advised to separate the data access code in a separate physical and logical module (or assembly in .Net language) so you can change it without affecting the overall application.
But when using this, the interface (the method signatures) should be made that abstract that they does not exactly map to the physical database schema but to the logical schema. Finally, if the database schema change is major (which is not a very good sign for the application overall design) then there is no solution but to change the code and ship the installation again!!
How do I set the connection string at installation :specific data provider?
Well this is quite tricky and interesting. Connection strings are database dependent and different database servers allow connection strings in different formats.
If you are using the database specific provider classes (like those from System.Data.SqlClient or System.Data.OracleClient) then you can generate the connection string easily by taking the specific inputs from the user. For example, if you are using SQL Server and the classes from the System.Data.SqlClient namespace then we can ask user the SQL Server instance name, the user name, password of if he/she is using the Windows Authentication to log in and the database name.
How do I set the connection string at installation :general data provider?
The problem arises when you are using the general data providers such as classes from System.Data.OleDb and System.Data.Odbc namespaces. You can’t make a general GUI to generate the connection string for all the database servers. Then what to do now? The solution is the DataLink Dialog.
How do I supply the connection string during first run or during the regular execution?
Well that should be very simple Just add the Data Link Properties dialog box at the start of the application or during the regular execution of the application whenever you need it. Alternatively, you can also provide your own designed user interface for connection string related properties, if your application supports specific .Net data providers (like System.Data.SqlClient or System.Data.OracleClient)
How do I store / retrieve the connection string in / from a text file?
You can store the connection string in the text file or an xml file and later retrieve it. Let’s see some example code to write a connection string to the text file and read it back .
How do I store / retrieve the connection string in / from an XML file?
Once you get the connection string, you can store the connection string in the text file or an xml file and later retrieve it. Let’s see some example code to write a connection string to an XML file and read it back .
RELATED POST
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART THREE
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FOUR
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FIVE
ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE
ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO
You can also learn the concept of frame work concept in detail with questions and answers in the following place.
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART ONE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TWO
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART THREE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FOUR
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FIVE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SIX
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SEVEN
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART EIGHT
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART NINE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TEN
Some of the basic issues related to the deployment of the data access applications are:
• Can we suppose the required database exists at the target location?
• If the database does exist then how can we get the connection string of it? Should we get it at the installation time? Or at the first run?
• If the database does not exist then how it can be created? Is it the responsibility of human installing our application? Or the application should create it at the time of installation?
• If the database is to be created by the application installation, then how does the installation setup know where (on which machine) to create the database? And what user name and password the setup should use to create the database?
• Once, the database is created or its connection string is found at the setup time, then how to store the connection string for later use (regular execution)?
What if the database address (connection string) is changed during the application life cycle then what should be the application behavior? How can the application be aware of the new connection string?
• If the database schema is hard-coded in the code (like table and field names) and the DB schema is changed (table/field name or data type is changed or new field/table added or some fields/tables deleted) because of any reason, then how to fix this problem?
You can see from the above points that the basic issue is the identification of the address (or connection string) of the database server. The most important point to remember here is that the application must perform in any condition and must not be crashed because of any condition and most of the problems (if not all) should be handled without any change in the code or any update patch installation
How do I solve the deployment issues ?
• The easiest and very sound solution is to provide the database script to create necessary database and tables along with the installation and ask your user to run the script on the target database server to create the required database. Then ask the user to supply the connection string at the installation setup time.
• You can create the database with the installation by executing the database creation script with the installation. But before this, you have to ask the user the location (the computer on the network) where the database server exists, and the user name, password to login to the database.
• The connection string should be stored in a text or binary or xml file. You can also encrypt the connection string before writing it to the file. The application, thus, is required to decrypt and load the connection string in the memory at each startup.
• The application should load the connection string at each startup and attempt to connect to the database. If the connection attempt fails then it should inform the user that the database is not available and ask the user to setup the database and try again. The application should also allow the user to change the database connection string any time and, it the application logic permits, let the user specify to work without database. If the user specifies a new connection string during the application startup or regular execution, the application should save it for later use.
• One solution to the schema changed problem is to use views and stored procedure wherever possible. But if this is not done or the change is too big to be catered by the views and/or stored procedure then you can supply a new data access module update (a new DLL may be). For this reason, it is advised to separate the data access code in a separate physical and logical module (or assembly in .Net language) so you can change it without affecting the overall application.
But when using this, the interface (the method signatures) should be made that abstract that they does not exactly map to the physical database schema but to the logical schema. Finally, if the database schema change is major (which is not a very good sign for the application overall design) then there is no solution but to change the code and ship the installation again!!
How do I set the connection string at installation :specific data provider?
Well this is quite tricky and interesting. Connection strings are database dependent and different database servers allow connection strings in different formats.
If you are using the database specific provider classes (like those from System.Data.SqlClient or System.Data.OracleClient) then you can generate the connection string easily by taking the specific inputs from the user. For example, if you are using SQL Server and the classes from the System.Data.SqlClient namespace then we can ask user the SQL Server instance name, the user name, password of if he/she is using the Windows Authentication to log in and the database name.
How do I set the connection string at installation :general data provider?
The problem arises when you are using the general data providers such as classes from System.Data.OleDb and System.Data.Odbc namespaces. You can’t make a general GUI to generate the connection string for all the database servers. Then what to do now? The solution is the DataLink Dialog.
How do I supply the connection string during first run or during the regular execution?
Well that should be very simple Just add the Data Link Properties dialog box at the start of the application or during the regular execution of the application whenever you need it. Alternatively, you can also provide your own designed user interface for connection string related properties, if your application supports specific .Net data providers (like System.Data.SqlClient or System.Data.OracleClient)
How do I store / retrieve the connection string in / from a text file?
You can store the connection string in the text file or an xml file and later retrieve it. Let’s see some example code to write a connection string to the text file and read it back .
How do I store / retrieve the connection string in / from an XML file?
Once you get the connection string, you can store the connection string in the text file or an xml file and later retrieve it. Let’s see some example code to write a connection string to an XML file and read it back .
RELATED POST
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART THREE
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FOUR
ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FIVE
ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE
ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO
You can also learn the concept of frame work concept in detail with questions and answers in the following place.
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART ONE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TWO
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART THREE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FOUR
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FIVE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SIX
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SEVEN
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART EIGHT
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART NINE
MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TEN
No comments:
Post a Comment