Hi All,

I have a couple of questions about Chapter 3 that I don't quite understand but should be easy for you experts. The questions are:

Q1) Page 106 has the ExecuteNonQuery method of the DataAccess class although I know what is doing I don’t really see the purpose of one part of it. Specifically I don’t see the point in changing the value of any parameters that the passed in command object may contain as the command will never run when the user is “sampleeditor”. So why bother giving the parameters of the command object passed in default values?

Q2) I don’t quite understand the point of using the base DbCommand object to run it’s methods (ExecuteNonQuery, ExecuteScalar, ExecuteReader) within our own methods within the DataAccess class. Why would you want to use the DbCommand object to do this when you can use the specific command objects, like SqlCommand, OracleCommand etc from your specific DAL class; especially as the specific command objects are optimised for their specific data source?

Any help would be appreciated.

Thanks

1) Sampleeditor was a hack added near the end of the devlopment cycle. He added it so people could see him demo site without messing up his data. No real site would use that, so he didn't spend any serious time optimizing it.

2) We do use the native object, but we're just abstracting it (you don't see any OleDb classes, right?). The idea is based on the fact that you might want to plug in an Oracle class tomorrow. You'd be in trouble if you tried to use it as a Sql Server provider, but if you drop down to the interface and trust that it will call the right implementation, you can keep most of your code database agnostic. Sometimes inheritance with virtual methods (vertical extensibility) is the answer. But if you have a sealed class, then you have to use the interface, instead (horizontal extensibility). Sometimes a combination can be used. As long as it calls the right code in the end, you're fine.

Eric

Thanks Eric.

Sorry Eric, having relooked at your answer to question 2 I still don’t understand the logic of doing this.

In our ExecuteNonQuery method within the DataAccess class we are not using the SqlCommand native object; we are using the DbCommand object. The SqlCommand object inherits from the DbCommand object. When we pass over our SqlCommand object it is implicitly converted into a DbCommand object. So we lose the extra functionality provided by the SqlCommand object as well as it’s optimised ExecuteNonQuery() method. You’ll note in the framework that the ExecuteNonQuery() method of the DbCommand object is overridden in the SqlCommand object. So the ExecuteNonQuery() method of the DbCommand object is the one being run within our own ExcuteNonQuery() method not the ExecuteNonQuery() method of the SqlCommand object. Also I’m not suggesting that we change the parameter to our ExecuteNonQuery() method to a SqlCommand object, I know that would be ridiculous; I just can not see the point in executing the ExecuteNonQuery() method of the DbCommand object in the base class when you can just execute the actual ExecuteNonQuery() method for the specific provider within the specific provider class itself, as you could also do for other specific provider classes. Remember these methods are overridden within each specific provider so why run the base DbCommand methods instead as you’ll be losing the optimised functionality of the overridden methods within each specific provider? I do understand why he’d want to put logging, replacement of strings etc in the DataAccess class but that’s all.

The only benefit I can see is a trade off. You have the advantage of only having to write the code that will execute commands once which all providers can use for all modules but you lose the optimised functionality of each specific provider implementation of the ExecuteNonQuery() method.

I suppose your implementation would vary based upon your situation. Is it logical to implement the generic providers if your classes will only EVER touch MS Sql Servers? No probably not. Would it be logical to implement this if you were swapping between Oracle and MS Sql on the fly? Maybe.

Personally I am in the former category, the applications that I design and work on will only ever touch MS Sql Servers (and if we ever migrate to Oracle or another RDBMS I am demanding a pay raise) so I implement the SQL providers throught my DataAccess class.

However, unless there was an enourmous preformance increase in implementing the provider specific classes, I would use this cure all to flip between servers. Really, I think, this comes down to a matter of opinion in how you specifically implement your class, however, Eric may have better logic than I as to why you would do this.

In any case, hth.

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from planoie's profile^^
^^Modified text taken from gbianchi profile^^
================================================== =========
Technical Editor for: Professional Search Engine Optimization with ASP.NET
http://www.wiley.com/WileyCDA/WileyT...470131470.html
================================================== =========
Why can't Programmers, program??
http://www.codinghorror.com/blog/archives/000781.html
================================================== =========

From what I'm experiencing, you cannot easily switch to an oracle database as the author intended. I'm connecting to Oracle database using the Oracle Provider (Oracle.DataAccess.Client). I get this error when trying to pass OracleCommand to the DataAccess class ExecuteReader(System.Data.Common.DbCommand) method. "Cannot Convert type Oracle.DataAccess.Client.OracleCommand to System.Data.Common.DbCommand"

You might get farther with the MS Oracle provider, but you'd hit a couple brick walls soon. None of the 2.0 providers are compatible with Oracle, so that means the most essential parts of the site can't work without a total redesign. Secondly, the stored procs and data model are tightly bound to SQL Server.

Oracle will release 2.0 provider support in the next major release of ODP. But you'll still be stuck on item 2.

I use Oracle on the job, and I ended up with a custom security model and state mechanism. TBH is not compatible with this - it would be like putting a Chevrolet body on a BMW chassis. They aren't going to fit, and it's not wise to make them fit by banging with a big hammer.

The author was only trying to demonstrate the idea (not the complete implementation) of RDBMS independence. Frankly, only a trivially simple DB model will ever be portable. And it would perform like a dog on all RDBMS's.

Eric