System.Data & System.Data.SqlClient vs. DatabaseFactory.CreateDatabase ??

  • Thread starter Thread starter TMC
  • Start date Start date
T

TMC

Hey All,

I was wondering if someone may be able to quickly enlighten me as to the
advantages of using the System.Data & System.Data.SqlClient namespaces as
opposed to the DatabaseFactory.

Anyone have preferences and why?

Thanks,

TC
 
Hey Sloan,

Right... should've refreshed on this one.

I'll give you some background on my specific situation so there is some
point of reference.

I'm semi-managing some guys that are working on an ASP.Net / SQL Server
backend app that's being extended. Their adding some small functionality.

Generally, I would think that using a DAL that is specific to SQL Server
would provide the best performance.

I don't see any specific reason that something more generic, etc. should be
used nor have I seen any reason to implement the Factory pattern vs. MVC.

However, considering these patterns can be quite abstract in nature and
considering my situation described above, do you see any reason someone
would be using that application block to implement the Factory pattern? ;-)

Thanks
 
I use Sql Server 200x 99.9% of the time.

I still use the EnterpriseLibrary.Data.

Why?

Because people alot smarter than me wrote it.
Its been tested and retested by thousands of more people than I could ever
test with.
My DAL routines are very , very "clean".

Set the stored procedure name.
Add input parameter values
Call a method

That's most of what you do.

There are "best practices" already in the library. So I don't have to
remember to put them in.


Go here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!176.entry

Look at this code:
CustomerSqlServerData.cs

Here is a sample method:

public CustomerDS CustomersGetAllWithOrdersDS() //a strong dataset
{

CustomerDS returnDS = new CustomerDS();
try
{
Database db = this.GetDatabase();//encapsulated method to
call the factory...I encapsulate it because sometimes I pass in the
DbInstanceName, and sometimes I rely on the default

DbCommand dbc =
db.GetStoredProcCommand(this.PROC_CUSTOMERS_GET_ALL); // a local CONST value
db.LoadDataSet (dbc , returnDS , new string[]{
returnDS.Customers.TableName , returnDS.Orders.TableName });
return returnDS;
}
finally
{
}
}

It doesn't get any cleaner (or maintainable) than that.
 
Fair enough ;-)





sloan said:
I use Sql Server 200x 99.9% of the time.

I still use the EnterpriseLibrary.Data.

Why?

Because people alot smarter than me wrote it.
Its been tested and retested by thousands of more people than I could ever
test with.
My DAL routines are very , very "clean".

Set the stored procedure name.
Add input parameter values
Call a method

That's most of what you do.

There are "best practices" already in the library. So I don't have to
remember to put them in.


Go here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!176.entry

Look at this code:
CustomerSqlServerData.cs

Here is a sample method:

public CustomerDS CustomersGetAllWithOrdersDS() //a strong dataset
{

CustomerDS returnDS = new CustomerDS();
try
{
Database db = this.GetDatabase();//encapsulated method to
call the factory...I encapsulate it because sometimes I pass in the
DbInstanceName, and sometimes I rely on the default

DbCommand dbc =
db.GetStoredProcCommand(this.PROC_CUSTOMERS_GET_ALL); // a local CONST
value
db.LoadDataSet (dbc , returnDS , new string[]{
returnDS.Customers.TableName , returnDS.Orders.TableName });
return returnDS;
}
finally
{
}
}

It doesn't get any cleaner (or maintainable) than that.






TMC said:
Hey Sloan,

Right... should've refreshed on this one.

I'll give you some background on my specific situation so there is some
point of reference.

I'm semi-managing some guys that are working on an ASP.Net / SQL Server
backend app that's being extended. Their adding some small
functionality.

Generally, I would think that using a DAL that is specific to SQL Server
would provide the best performance.

I don't see any specific reason that something more generic, etc. should
be used nor have I seen any reason to implement the Factory pattern vs.
MVC.

However, considering these patterns can be quite abstract in nature and
considering my situation described above, do you see any reason someone
would be using that application block to implement the Factory pattern?
;-)

Thanks
Click to expand...
Click to expand...
 
Back
Top