Re: Triple Whammy Newbie Question - abstracting connections/commands
From: Mary Chipman [MSFT] (mchip_at_online.microsoft.com)
Date: 02/10/05
- Next message: J Sawyer [Microsoft]: "RE: problems with a stored prc"
- Previous message: RJ: "Re: Can't retrieve any schema info in UDB"
- In reply to: J L: "Re: Triple Whammy Newbie Question - abstracting connections/commands"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 10 Feb 2005 12:38:29 -0500
Unfortunately, ADO 2.0, although much improved, still won't get you
where you want to go. My opinion is, and it isn't politically correct
and is not what is considered best practice, is that dynamic strings
are the way to go for your particular application since you are
performing all of the necessary validation up front. You'll just have
to make sure that your servers are locked down tight and strictly
monitored, because this path requires that permissions be granted on
the base tables. So anyone getting in can have a field day on the data
(not necessarily breaking in via your app, but by other means).
--Mary
On Wed, 09 Feb 2005 19:45:47 -0800, J L <john@marymonte.com> wrote:
>Hi Mary,
>Since my last post, I have been reading a lot about DataFactories and
>using interfaces to create a generic data access layer. This sounds
>like the solution. I also thought I read that ADO.Net 2.0 has a
>DataFactory? (Since I am so new to .Net and ADO.net, I do not even
>know what version is the current one). It seems so obvious to put that
>layer between the physical and the UI or BLL that I do not understand
>why MS has not done this as part of the ADO.Net product. Although
>Silvano Coriani wrote a good article on MSDN about how to do it.
>
>As for security, my apps are very specific to data collection in the
>food industry. I am not exposed to people making ad hoc requests of my
>data and I do not use bound data controls. I handle and validate all
>input before accessing the database. So an SQL injection would never
>happen since the damaging strings would not pass my validation
>requirements.
>
>Really all I need is the good ole DAO recordset! LOL...old habits die
>hard I guess.
>
>Thanks,
>John
>
>On Wed, 09 Feb 2005 21:06:53 -0500, "Mary Chipman [MSFT]"
><mchip@online.microsoft.com> wrote:
>
>>Yes, that is one way around it -- don't use parameterized statements
>>or stored procedures and create your SQL statements on the fly. But
>>that means that you are potentially leaving yourself wide open to SQL
>>injection attacks and are unable to leverage the security features
>>that stored procedures and parameterized commands provide. Not a good
>>tradeoff, I'm afraid.
>>
>>--Mary
>>
>>On Tue, 08 Feb 2005 16:39:59 -0800, J L <john@marymonte.com> wrote:
>>
>>>Hi Mary,
>>>Thank you for clarifying the issue for me.
>>>
>>>I had hoped there was a "minimum level" of compatibility between the
>>>providers above the Connection level, that I could program against and
>>>over-ride if need be to use more specific features. For example, I
>>>dont use stored procedures or parameters. So I would think a gneric
>>>Command object and hence a generic DataAdapter, DataReader would be
>>>possible.
>>>
>>>But we have to work with what we are given. And I do thank you for
>>>clarifying.
>>>
>>>John
>>>
>>>On Tue, 08 Feb 2005 14:43:16 -0500, "Mary Chipman [MSFT]"
>>><mchip@online.microsoft.com> wrote:
>>>
>>>>You can only write generic code that goes against multiple data
>>>>providers up to a point -- and that point is Command objects. The
>>>>problem is that each provider has its own syntax for handling
>>>>parameters, so it ends up being impossible to provide an elegant
>>>>solution without writing branching code that is provider-specific. The
>>>>reason your old VB6 code worked with DAO/SQL Server is because when
>>>>you used DAO with SQL Server, Jet was loaded under the covers and
>>>>provided the translation into ODBC-T-SQL for you. So you were going
>>>>through multiple layers--DAO-Jet-ODBC-SQL Server, which might have
>>>>been fine for a small database with few users, but was inherently
>>>>limited and not at all scalable.
>>>>
>>>>--Mary
>>>>
>>>>On Mon, 07 Feb 2005 20:01:05 -0800, J L <john@marymonte.com> wrote:
>>>>
>>>>>Thank you Keanen for your response. The MS site says to program
>>>>>against the IDBConnection, etc. I have no idea how to do that.
>>>>>
>>>>>What I was hoping was to be able to be able to create a generic object
>>>>>(e.g. Connection) and then have a routine that would cast it as the
>>>>>OleDB or SQLDb version based on an application's configuration
>>>>>parameters. But it seems that System.Data only implements the DataSet
>>>>>objects and not the provider type...too bad.
>>>>>
>>>>>Is the following code legal (i.e. putting different Dim statements
>>>>>within an If-Then-Else clause? (I hope this is not a really stupid
>>>>>question...but hey, if I dont ask I will never know)
>>>>>
>>>>>If USE_SQL then
>>>>> dim conn as New SQLDb.Connection( <some connection string stuff>)
>>>>> dim cmd as New SQLCommand
>>>>> dim da as New SQLDataAdapter()
>>>>>Else
>>>>> dim conn as New OleDB.Connection(<some connection string stuff>)
>>>>> dim cmd as New OleDBCommand
>>>>> dim da as New OleDBDataAdapter()
>>>>>End If
>>>>>
>>>>>< work with the above ojects here in a general way>
>>>>>
>>>>>TIA,
>>>>>John
>>>>>
>>>>>On 7 Feb 2005 08:15:17 -0800, "Keanen"
>>>>><SpamFromGoogleGroups@farrlink.com> wrote:
>>>>>
>>>>>>As far as I know, there is no real way to generalize everything except
>>>>>>to create a separate data access layer that contains all the code that
>>>>>>accesses your database (one for each flavor of database you want to
>>>>>>access). Then I've seen some people have that pass back generic
>>>>>>datasets to another layer or you can have the data access layer
>>>>>>populate an object by itself.
>>>>>>
>>>>>>Here is a helpful article:
>>>>>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp
>>>>>>
>>>>>>Keanen
>>>>>>
>>>>>>J L wrote:
>>>>>>> Let me clarify...in VB6 since there was only one flavor of DAO, I
>>>>>>> could use a general purpose routine that created the database
>>>>>>> connection via Opendatabase() to either Access or SQL based on a user
>>>>>>> defined configuration. Now with ADO.Net there are at least two
>>>>>>> versions of every thing in the set of Provider Objects (Connection,
>>>>>>> Command, DataAdapter and DataReader). How can I create a generic
>>>>>>> method to use either the SQLdb. or the OleDb. objects so the rest of
>>>>>>> my application can be oblivious to the underlying data source? Or
>>>>>>does
>>>>>>> this question even make sense?
>>>>>>>
>>>>>>> TIA
>>>>>>> John
>>>>>>>
>>>>>>> On Sun, 06 Feb 2005 09:30:36 -0800, J L <john@marymonte.com> wrote:
>>>>>>>
>>>>>>> >I am new to .Net, ADO.Net and OOP programming. Have plenty of
>>>>>>> >experience with VB6 and DAO but now need to move on. Here is my
>>>>>>simple
>>>>>>> >question:
>>>>>>> >
>>>>>>> >I want to create a procedure or class that will handle the creation
>>>>>>of
>>>>>>> >connections and commands at runtime so that the rest of my code will
>>>>>>> >not have to know if I am using OleDB, SQLDb or something else.
>>>>>>> >
>>>>>>> >I hope that is stated clearily. If not, please prod me along the
>>>>>>right
>>>>>>> >path...I need to be enlightened :>)
>>>>>>> >
>>>>>>> >John
- Next message: J Sawyer [Microsoft]: "RE: problems with a stored prc"
- Previous message: RJ: "Re: Can't retrieve any schema info in UDB"
- In reply to: J L: "Re: Triple Whammy Newbie Question - abstracting connections/commands"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
