Mymsdntvlibrary (http://blog.joycode.com/musicland/posts/13776.aspx) is a small WinForms project I have written before. At that time, the idea was to demonstrate how to create a simple but complete small project. Many friends are very interested in this simple little thing. A friend in Xi'an will even add a new function to add TV after watching the source code. This makes me feel very pleased.
Just recently reviewed the design model, I began to re-examine the original application structure and found some places that should be improved. For example, I am very easy to support different kinds of data sources, such as Access, SQL Server, and even simple XMLs, such as Access, SQL Server, or even simple XML. I know that it is not difficult to achieve, but how can you do the most effective than code multiplexing? I want to go, I decided to apply Factory Method mode in the data access.
Factory method is a mode given in GOF in the DESIGN PATTERSN book, and GOF is defined for it:
DEFINE An Interface for Creating An Object, But Let Subclasses Decide Which Class To Instantiate. Factory Method Lets a Class Defer Instant To Subclasses.
Simply, the purpose of Factory Method is to create a few similar (realizing the same interface or continue the same parent class) class. In order to achieve this, you need to create several similar Creator classes, come through the Creator class. Decide which one of the required object classes created. Its UML is shown below:
For this project, I need to create several different DBHELPERs for different data sources (my personal habits are encapsulated by DBHELPER), such as OLEDBHELPER, SQLDBHELPER, etc. These Helper has Very similar structure, so you can continue to contact the same interface - IDBHELPER. The IDBHELPER is defined as follows:
Using system;
Using system.data;
Namespace Musicland.msdntVlibrary.Component
{
Public interface IDBHELPER
{
DataSet getAll ();
}
}
Note that a method GetAll that is to be implemented is given, and all the data required for the application can be obtained by implementing the call to the method.
Next is two specific data access assist classes that continue from IDBHELPER.
OLEDBHELPER:
Using system;
Using system.configuration;
Using system.data;
Using system.data.oledb;
Namespace Musicland.msdntVlibrary.Component
{
// this is the helper class thing will interact with oledb for info.
INTERNAL CLASS OLEDBHELPER: IDBHELPER
{
Private OLEDBCONNECTION CONN;
Public oledbhelper ()
{
CONN = New OLEDBConnection (ConfigurationSettings.appsettings "]);
}
Public DataSet getAll () {
OLEDBDATADAPTER Da = New OLEDBDataAdapter ("Select * from episode order by date desc", conn;
DataSet DS = New Dataset ();
Try
{
Da.fill (DS, "EPISode");
}
Catch (OLEDBEXCEPTION EX)
{
Throw EX;
}
Finally
{
IF (conn.state! = connectionState.closed)
CONN.CLOSE ();
}
Return DS;
}
}
}
Sqldbhelper:
Using system;
Using system.configuration;
Using system.data;
Using system.data.sqlclient;
Namespace Musicland.msdntVlibrary.Component
{
// this is the helper class thing will interact with sqlserver for info.
INTERNAL CLASS SQLDBHELPER: IDBHELPER
{
SqlConnection conn;
Public SqldBhelper ()
{
CONN = New SqlConnection (ConfigurationSettings.AppSettings ["SqlConncectionstring"]);
}
Public Dataset getAll ()
{
SQLCommand cmd = new sqlcommand ("getall", conn);
cmd.commandtype = commandtype.storedProcedure;
SqlDataAdapter Da = New SqlDataAdapter (CMD);
DataSet DS = New Dataset ();
Try
{
Cn.open ();
Da.fill (DS, "EPISode");
}
Catch (SQLException EX)
{
Throw EX;
}
Finally
{
IF (conn.state! = connectionState.closed)
CONN.CLOSE ();
}
Return DS;
}
}
}
The code is simple, which is for different data sources to get all the contents of the EPISODE table (because the number of programs required for this application is very small, the structure is also very simple, so an EPISODE table is sufficient). Among them, I use the SQL statement directly to use the SQL statement to query directly, and this part of SQLDBHELPER for SQL Server is used to use the stored procedure, which greatly reflects the difference in access to different data sources.
The data accessed the auxiliary class has been built, and the Creator and ConcreteCreat port will be created to dynamically call these auxiliary classes. OK, create an IDBCREATRO interface:
Using system;
Namespace Musicland.msdntVlibrary.Component
{
Public interface IDBCREATOR
{
IDBHELPER CREATEDBHELPER ();
}
}
By implementing this interface, we can get specific classes for creating different data access assist classes:
OLEDBCREATOR:
Using system;
Namespace musicland.msdntvlibrary.Component {
// this is the concretecreator class what help
// Create and return The OLEDBHELPER CLASS.
Public Class Oledbcreator: IDBCREATOR
{
Public oledbcreator () {}
Public idbhelper createdbhelper ()
{
Return new oledbhelper ();
}
}
}
SQLDBCREATOR:
Using system;
Namespace Musicland.msdntVlibrary.Component
{
// this is the concretecreator class help
// CREATE AND RETURN The SqldBhelper Class.
Public Class Sqldbcreator: IDBCREATOR
{
Public Sqldbcreator () {}
Public idbhelper createdbhelper ()
{
Return new sqldbhelper ();
}
}
}
The above two classes have realized the IDBCREATOR interface. By implementing the CREATEDBHELPER method, you can create an instance of a data access assist class (OLEDBHELPER or SQLDBHELPER) and transfer to the callback, which is exactly what we need.
OK, the main framework has been set up, and then we only need to call through the appropriate logic in the application. My initial imagination is to add a custom DBTYPE button in the .config file, which determines which data access method that the application needs to be set for DBTYPE. The configuration file part is as follows:
NOTE: DBTYPE INDICATES for DB NEED TO Interact with.
Currently:
0: SQLServer
1: OLEDB
->
...
Appsettings>
After setting up DBTYPE, we have to do just read this configuration value in the application, then create the corresponding dbcreator, the code is as follows:
// Get the Corresponding IDBCREATOR CLASS
Public static idbcreator getdbcreator ()
{
INT dbtype = convert.Toint32 (ConfigurationSettings.AppSettings ["DBTYPE"]);
Switch (DBTYPE)
{
Case 0:
Return New Sqldbcreator ();
Case 1:
Return new oledbcreator ();
DEFAULT:
Return new oledbcreator ();
}
The above code can return a specific dbcreator that implements the IDBCREATOR interface, that is, OLEDBCREATOR or SQLDBCREATOR, you get the DBHELPER you need to get the application by calling the CREATEDBHELPER method implemented by this class:
// get the corresponding idbhelper class
Public static idbhelper getDbhelper (idbcreator dbcreator)
{
Return dbcreator.createdbhelper ();
}
In this way, the application can dynamically adopt a specific data access method for a particular data source.
OK, I have extended mymsdntvlibrary through a simple example, and also illustrate the application of Factory Method in the specific application. Of course, the design pattern is more than this, and the application of Factory Method is not limited thereto. The environment I have given is just a very small special case. In more case, different design patterns need to be combined with the application (Patternal to Solve A Problem). Below I recommend some books and information about design patterns, I hope to help everyone:
Design Patterns - Elements of Reusable Object-Oriented Software (Design Mode - Object-Oriented Software Basics) (Too Classic) Design Perspective ON Object-Oriented Design (Design Mode Analysis) (combined with one Book learning) C # design patterns: a tutorial (C # design mode) (full with C # implementation, there is a certain reference value) Data & Object Factory Update:
After JGTM'2004 [MVP], I repeatedly reimbursed the environment described above. By increasing the form of the plug-in (inherited a assembly in the iProvider interface), library supports the multi-proportion of multi-claims from true sense without having to Re-compile, from the true sense to unplugged. For specific implementation, see JGTM'2004 [MVP] given a wonderful reply given after text. If you are interested, you can download all the source code here (thank you Johnnyhu to provide space!).
