C#

Re: functions vs properties

WPHC — Fri, 17 Jul 2009 23:54:20 GMT

really? Because I can pick peoples brains for hours............................

the amended code that you put up for VS2005 didnt work...

Re: functions vs properties

JeffreyABecker — Fri, 17 Jul 2009 17:40:42 GMT

Honestly I like this sort of thread. Its a great distraction over my lunch break.

Re: functions vs properties

WPHC — Fri, 17 Jul 2009 00:02:02 GMT

thanks for the feedback :)

i have inheritance down pack :) that took me a fair while to get.

I still cant get your code to work - still getting errors - i think i might leave it - one day i might get it....

Thank you for your help, you have been very patient and i do not wish to bother you any more then I already have...

Re: functions vs properties

JeffreyABecker — Thu, 16 Jul 2009 18:49:13 GMT

It all boils down to abstraction, encapsulation and polymorphism. To some extent interfaces get you all three. Dont worry, about not 'getting it'. This stuff is HARD.

Re: functions vs properties

WPHC — Thu, 16 Jul 2009 01:23:33 GMT

on hind sight - i dont ever think i will understand interfaces :(

and i have a feeling that isnt a good thing either

Re: functions vs properties

WPHC — Wed, 15 Jul 2009 22:33:42 GMT

ah the penny drops about interfaces.....i think

I tried looking at the code here..but its still the same error

http://pastebin.com/f20fcc5ca

Re: functions vs properties

JeffreyABecker — Wed, 15 Jul 2009 13:18:59 GMT

Right, no automatic property implementations in 2k5. Try now.

The reason to use an interface is mostly about abstraction. The interface keeps everyone honest. Consuming classes dont know about details or extra members that the implementing class exposes so they cant call them.

Re: functions vs properties

WPHC — Tue, 14 Jul 2009 21:31:15 GMT

for the new code that you pasted up

i get these errors

Error   1   'JB.DbExample.DbArg.Name.get' must declare a body because it is not marked abstract or extern       28   30
Error   2   'JB.DbExample.DbArg.Name.set' must declare a body because it is not marked abstract or extern       28   35
Error   3   'JB.DbExample.DbArg.Value.get' must declare a body because it is not marked abstract or extern       29   31
Error   4   'JB.DbExample.DbArg.Value.set' must declare a body because it is not marked abstract or extern       29   36

Re: functions vs properties

WPHC — Tue, 14 Jul 2009 21:28:06 GMT

Hey Jeffery,

sorry about the delay in response, life is a little un-organised at the moment

1.) i added a .CS file to my app_code

2.) i pasted in the code

3.) ctrl + shift +b (build the code) and it came up with these errors

Error   1   Type expected       90   36
Error   2   Identifier expected, 'string' is a keyword       90   56
Error   3   Identifier expected, 'object' is a keyword       90   73
Error   4   ; expected       90   88
Error   5   Invalid token '(' in class, struct, or interface member declaration       92   27
Error   6   Invalid token ',' in class, struct, or interface member declaration       92   36
Error   7   Class, struct, or interface method must have a return type       92   38
Error   8   Identifier expected       92   64
Error   9   ; expected       92   65
Error   10   Expected class, delegate, enum, interface, or struct       94   23
Error   11   Expected class, delegate, enum, interface, or struct       98   23
Error   12   Expected class, delegate, enum, interface, or struct       102   23
Error   13   Type or namespace definition, or end-of-file expected       224   1

VS2005 Pro

======================

just on a side question - answer only if you feel like it,

what if you just set up a class that had methods, that returned datasets? why would you use an interface class?

Re: functions vs properties

JeffreyABecker — Tue, 14 Jul 2009 13:50:55 GMT

Theres actually very little in there thats 3.5 specific. What version of visual studio are you running and what type of project do you have set up?

Heres a version w/ all the 3.5 specific stuff pulled out: http://pastebin.com/f20fcc5ca

usage is something like:

using(IDbManager db = DbManagerFactory.GetDbManager("Northwind"))
{
	DataSet ds = db.Exec("getSalesPersonByName", new DbArg("name","Bob"));
}

Re: functions vs properties

WPHC — Mon, 13 Jul 2009 06:39:47 GMT

i could not get this to work

was this designed for .net 2.0 - i dont think so as it has link

do you have a version for 2.0?

Re: functions vs properties

WPHC — Sun, 05 Jul 2009 23:23:59 GMT

ah yes you are right i am confusing the interface class with implementation class :)

I am going to have a go at working with the code....and see if i can get it to work

and see what i can bind :) thanks heaps

Re: functions vs properties

JeffreyABecker — Sun, 05 Jul 2009 20:04:17 GMT

also, I noticed a bug where I was forgetting to setup transactions. Please take a look at the updated pastebin

Re: functions vs properties

JeffreyABecker — Sun, 05 Jul 2009 19:56:31 GMT

first a little note on interfaces:
The interface I declared is functionally equivlent to:

public abstract class IDbManager : IDisposable
{
    public abstract DataSet Exec(string procName, params DbParameter[] args);
    public abstract DataSet ExecDynamicSql(string sql, params DbParameter[] args);
    public abstract T Scalar<T>(string procName, params DbParameter[] args);
    public abstract T ScalarDynamicSql<T>(string sql, params DbParameter[] args);
    public abstract void Begin();
    public abstract void Commit();
    public abstract void Rollback();
    public abstract void Dispose();
}

In C# you can only ever inherit from one class, but you can implement multiple interfaces. So its better to declare such things as interfaces. Also, classes that inherit from such interfaces are said to 'implement' them.

====

WPHC:
So by that you mean an interface class is always inherited (i just read up on interfaces now and understand them a bit better - although they still confuse me)

Exactly. You cant actually put any implementation in an interface. the compiler will start throwing errors.

WPHC:
correct me if i am wrong (and i will take your word over mine) but from my reading, my understanding is that Interface classes are not supposed(should not?)
to contain any 'body' connection code? Although i do understand why you did this, because if you ever swap dbases all you have to do is change it in the one spot, instead of
the whole application.

I think you might be getting confused between the interface and the class which 'implements' it.

WPHC:
That one i knew, but i think i was asking a different question

Oh, umm yes that function is for executing straight sql that isnt a stored procedure?

WPHC:
This one i still donot get - even after i have looked through my reading material, do you have a link which would give me a starting point?

I think the microsoft tutorial on generics is a good start:
http://msdn.microsoft.com/en-us/library/ms379564.aspx

Re: functions vs properties

WPHC — Sat, 04 Jul 2009 23:40:54 GMT

line 11)Right. This class is the class that actually 'implements' the interface. Remember, interfaces are completly abstract. you can never actually instantiate one directly. instead you must create a class that implements that interface and instantiate that. SqlDbManager is the class that does the implementation.

//**************So by that you mean an interface class is always inherited (i just read up on interfaces now and understand them a bit better - although they still confuse me)

line 20 / 27) The IDbManager interface abstracts away a lot of stuff. Most importantly it completely hides connection management.
This particular line simply sets the connection string that this implementation will use. Then the first time someone trys to do anything the connection is opened.
I use a method here because of the transaction management portion of the interface. If I simply opened and closed a connection in each call,
1) performace could start sucking 2) You couldnt do transactions.

//**************correct me if i am wrong (and i will take your word over mine) but from my reading, my understanding is that Interface classes are not supposed(should not?)
to contain any 'body' connection code? Although i do understand why you did this, because if you ever swap dbases all you have to do is change it in the one spot, instead of
the whole application.

line 40) Yes. My personal experience is that DataReaders are a lot of work, for very little payoff. My expericene is that 'use data readers' is premature optimization.
I once had an app that used data sets which performed poorly. The admonition came down to rewrite it to use data readers. 2 weeks later,
I had an app which was much harder to understand and still preformed poorly. When we actually profiled the app, it turned out we were performing O(N^2) operations on much
larger data structures that were originally envisioned. If you wanted something other than a DataSet out of the methods, I'd suggest IEnumerable<IDataRecord>.
Both DataReaders and DataTables implement, or can be adapted to implement IEnumerable<IDataRecord>, but again I just prefer the DataSet api.

//***************** OK

line 41)This class is written to use SqlServer. I believe all that would be needed to use MySql would be to add a "using MySql.Data.MySqlClient;" in place of
"using System.Data.SqlClient" and add "My" infront of every "Sql". I dont really know the details of MySql though.

//************ that is probably the best news i have heard all week - not because im a lazy programmer, but because I do not know enough about Interfaces yet
(as well as that I have only just been introduced to datasets)

line 56)Yes. You can still parameterize sql even if its not a stored procedure. This is infact the recomended practice. It greatly mitigatges your risk of sql injection attacks.
//*********** That one i knew, but i think i was asking a different question...oh well you have been so helpful so far :) - they should promote you to moderator :)
(at least until i get an invoice in the mail for the tuition fees :) )

line 71/77) These two functions are 'generic' functions. C# supports parameterizing code by types similar to C++ templates. In this case T is the type parameter for the
output. These functions could be changed to return object if you're more comfortable with that. However the DataSetExtensions library provides a powerful,
generics based method of properly casting / converting the output of database operations. I've found these methods to be more complete and reliable than anything
I've ever written.

//****************************This one i still donot get - even after i have looked through my reading material, do you have a link which would give me a starting point?

Thank you for helping me to understand your code, and for the explanations - on monday i will play with it and make it work