StrataFrame Forum
Home      Members   Calendar   Who's On
Welcome Guest ( Login | Register )
      



Generic Data Access for Custom MethodsExpand / Collapse
Author
Message
Posted 03/12/2008 10:28:44 AM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 09/27/2008 2:00:26 AM
Posts: 152, Visits: 459
What is the best way to write custom methods to be generic for data access ? Plus, It must not have a conflict with the framework ?

FillDataTable method of business object accept System.Data.Common.DbCommand. I use this method to run commands.

Do I handle provider specific properties "SqlCommand and SqlParameter", "OracleCommand and OracleParameter" with my coding or any other alternative exists in the framework. 

Post #14816
Posted 03/12/2008 11:07:39 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: Today @ 3:06:58 PM
Posts: 4,599, Visits: 4,576
It sounds like you are trying to program your application so that you can swap between SQL and Oracle.  The first thing that you need to do is create a base business object class that inherits from our BusinessLayer.  Then all of your business objects will inherit from this base business object.

Once this is done, you will need to have some way of determining what database type is being run within the BO.  You could create a property on the base BO if you have the need for this to be determined on a per BO basis, otherwise, just create a shared property in a class that indicates what you are using.

Public Enum DatabaseType As Integer
    SQLServer = 0
    Oracle = 1
End Enum

Public Class MyBaseBo
    Inherits MicroFour.StrataFrame.Business.BusinessLayer

    Private Shared _DatabaseQueryType As DatabaseType = SQLServer

    Public Shared Property DatabaseQueryType As DatabaseType
        Get
           Return _DatabaseQueryType
        End Get
        Set (Byval value As DatabaseType)
            _DatabaseQueryType = value
        End Set
    End Property

    Private Function ConvertSqlToOracleCommand(Byval cmd As SqlCommand) As OracleCommand
       '-- Convert the SqlCommand into an Oracle Command
    End Function

    '-- Override the base FillDataTable and add a test to see if the command should be converted to Oracle
    Public Overrides Sub FillDataTable(Byval cmd As DbCommand)
        If MyBoBase.DataQueryType = Oracle Then cmd = ConvertSqlToOracleCommand(cmd)

        MyBase.FillDataTable(cmd)
    End Sub
End Class

When you develop your application, you should always code for a single database type.  This makes life much easier from a development stand-point.  You can then convert from your default command into the exception.  For example, you can see in the pseudo class above that I overwrote the FillDataTable and added a test to see whether I needed to convert the SqlCommand (which is what I would be expecting from my code) into an Oracle command.

Post #14817
Posted 03/13/2008 2:11:39 AM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 09/27/2008 2:00:26 AM
Posts: 152, Visits: 459
Thanks for the solution. I 'll will continue with the way you have explained for the command object. But what about the parameter objects ?

I'm trying to write a query class (But complex query text is supplied with XML documents) with parameters. The paramters will be extracted with parsing the query. For the parameters collection, I will need provider specific parameter class.

What should I do ? Should I follow same way as with command object ?

Post #14836
Posted 03/13/2008 8:56:31 AM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: 09/26/2008 8:30:36 AM
Posts: 2,685, Visits: 1,886
Yes, the SqlCommand.Parameters collection only accepts SqlParameter objects, while the OracleCommand.Parameters collection only accepts OracleParameter objects (and so forth: OleDbCommand.Parameters -> OleDbParameter, etc.).

Other than chaning the object type, you can generally use the same parameter.Value and stick with setting the parameter.DbType property to define the parameter's database type.  There are very few cases where you will have to set the provider-specific type (SqlParameter.SqlDbType or OracleParameter.OracleType).  The DbType is shared by all providers.

Also, when you're creating/converting parameters, remember that some commands use ? as the placeholder for parameters and go off of the order of the parameters, while others use @name or :name for parameters and link off of the name of the parameter.

If you're only going between Oracle and SQL Server, then you'll just have to swap the @ and : since they both use named parameters.  But, if you're using DB2 or Access (or other OLE DB or ODBC connections), then you'll have to ensure the order of the parameters matches the use of them within the command and use ? as the placeholders.


www.bungie.net
Post #14839
« Prev Topic | Next Topic »


Reading This TopicExpand / Collapse
Active Users: 0 (0 guests, 0 members, 0 anonymous members)
No members currently viewing this topic.
Forum Moderators: Ben Chase, Trent L. Taylor, Steve L. Taylor

PermissionsExpand / Collapse

All times are GMT -6:00, Time now is 3:54pm

Powered by InstantForum.NET v4.1.4 © 2008
Execution: 0.109. 9 queries. Compression Enabled.
Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.