C# Discussion Boards - CodeProject

29-Jun-10 1:46

Hallo everybody,

I'm doing a sample of project which has a base class and other two or more subclasses of the base class.
The base class is directly connected to a database when the time is to run.
My questions are the following:

1. Is it necessary to embed the connection properties every-time in the subclasses?
2. The same question, but little confusing for me, here it goes:

cmd = new SqlCommand("sql statement", con);// found in one of the subclasses

Both cmd and con are instances of the class SqlCommand and SqlConnection respectively.
Why is con necessary here? I mean, once a connection is established in a base class and inherited in the subclasses,
then why?

If I might not be clear enough, please let me know.

Thank you

J4amieC29-Jun-10 2:23

J4amieC

29-Jun-10 2:23

Yonathan1111 wrote:
If I might not be clear enough, please let me know

Its not clear what your question is. post some code.

Yonathan111130-Jun-10 20:37

30-Jun-10 20:37

Thank you for your cooperation.
I don't have code sample, it is a design. I'm asking what logic should I follow?

Thanks

Richard MacCutchan29-Jun-10 2:42

Richard MacCutchan

29-Jun-10 2:42

Yonathan1111 wrote:
1. Is it necessary to embed the connection properties every-time in the subclasses?

No, you can put the connection data anywhere, as long as the subclass can reach it at run time.

Yonathan1111 wrote:
Why is con necessary here?

The SqlCommand object needs access to the SqlConnection object in order to know which database it is referring to. Your program could be accessing multiple databases.

It's time for a new signature.

Yonathan111130-Jun-10 20:39

30-Jun-10 20:39

Thank you
You gave me a hint.

Thanks

PIEBALDconsult29-Jun-10 3:47

PIEBALDconsult

29-Jun-10 3:47

The Connection and Command should be embedded in a separate Data Access Layer class, which the others all use as necessary.

Yonathan111130-Jun-10 20:43

Automated UI Tests of GDI

30-Jun-10 20:43

Thank you very much, that is what I want.
Thnks

Berlus29-Jun-10 1:39

Berlus

29-Jun-10 1:39

Hello All,

I'm writing a dll that paints on the screen a gdi object.

How would you recomed me to perform automated UI test ?

I would like to draw the gdi object on the screen and compare it with a storded image.

I know I can caputre the screen and compare it to that image, but i was thinking maybe using the visual studio 2010 UI Automated test.

Thanks,
berlus

Re: Automated UI Tests of GDI

Ennis Ray Lynch, Jr.29-Jun-10 3:40

Ennis Ray Lynch, Jr.

29-Jun-10 3:40

I don't personally believe in automated GUI tests.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting.

A man said to the universe:
"Sir I exist!"
"However," replied the universe,
"The fact has not created in me
A sense of obligation."
--Stephen Crane

Insert variable into string

lukeer29-Jun-10 1:37

lukeer

29-Jun-10 1:37

Hello experts,

which advantages does one of these two methods

return (string.Format("Device #{0}", devNr));
return ("Device #" + devNr.ToString());

have over the other one?
They seem to produce identical results.

Ciao,

luker

Łukasz Nowakowski29-Jun-10 1:56

Łukasz Nowakowski

29-Jun-10 1:56

They produce identical results. The first one is consider better because it uses less memory. The second version allocates memory for 3 strings ("Device #", result of devNr.ToString() and result of entire statement), which makes application consume more memory. The first one isn't (to my knowledge) creating such an overhead. If you need to use second form it's better to use StringBuilder class. And personally I consider first form more readable.

Rhys Jacob29-Jun-10 2:52

Rhys Jacob

29-Jun-10 2:52

lukasz_nowakowski wrote:
And personally I consider first form more readable.

I agree, String.Format is more readable, especially when you have a few more arguments.

Keith Barrow29-Jun-10 4:13

Keith Barrow

29-Jun-10 4:13

I totally agree the 1st form is better, just on readability alone.

I'd question your point about the StringBuilder as a replacement for the second form, creating an instance of this type has some overhead, for small concatenations the string builder is worse than the code supplied in the OP, but it has become received wisdom that StringBuilder is more efficient.

I posted a link a while back http://www.yoda.arachsys.com/csharp/stringbuilder.html[^] to an archive of stuff John Skeet has written about c# amongst others. He has tested the received wisdom, and found it wanting, the section "So I Should Use StringBuilder Everywhere, Right?" is really the nub of the problem.

It's worth doing the test he suggests, for "small" concats the overhead of the StringBuilder outweighs the benefits (and dirties the code). For multiple concats (e.g. in a loop)

StringBuilder<code> is much more efficient.<br />
<div class="signature"><small>Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.<br />
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.</small></div>

William Winner29-Jun-10 8:47

William Winner

29-Jun-10 8:47

Interestingly, the String.Format uses a StringBuilder...

Keith Barrow29-Jun-10 11:04

Keith Barrow

29-Jun-10 11:04

I'm not convinced String.Format is more efficient than the straight concat, but I do think the format route is clearer.

Disassembling String.Format gives this line:

StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));

So it is likely that, as long as the argument passed average 8 characters or less, the StringBuilder will probably be more efficient at first glance. Of course, I haven't tested this, but it would be easy to rig a test to find out.

The point I was trying to make was that the assumption that StringBuilder is always more efficient than direct string manipulation is demonstrably false. Additionally, I'd say, unless the code is a block you know will be heavily repeated, early optimisation will ruin otherwise clear code without real benefit. I personally would only consider using a StringBuilder when I know this is the case, or testing reveals poor performance, or the system must perform with the highest possible efficiency for some reason(e.g. real time). This is in line with the KSS and YAGNI principles.

Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.

William Winner29-Jun-10 11:17

William Winner

29-Jun-10 11:17

I wasn't arguing for StringBuilder. I was just noting that you were saying for smaller concats, StringBuilder won't be more efficient. You were saying you preferred format 1 (albeit for readability) and I was just pointing out that format 1 used a StringBuilder which you were seeming to argue against.

I was just pointing out the irony is all.

For what he wrote, I would always lean towards the second format. Especially now that I've seen the path String.Format(String, Object) takes:

String.Format(String, Object) calls
String.Format(IFormatProvider, String, Object[]) calls
StringBuilder(int capacity) and StringBuilder.AppendFormat(IFormatProvider, string format, params object[] args) and StringBuilder.ToString() which calls
string.FastAllocateString(int length) then concatenates each of the StringBuilder parts.

It's way more code being run.

kevinnicol29-Jun-10 7:08

kevinnicol

29-Jun-10 7:08

Not to mention that the first form makes localization easier between english and any of {French, Spanish, Italian, etc..}

PIEBALDconsult29-Jun-10 14:36

PIEBALDconsult

29-Jun-10 14:36

Yes, I was going to make that point too.

William Winner29-Jun-10 8:12

William Winner

29-Jun-10 8:12

I'm just curious about something here. The header for String.Format looks like:

string Format(string strInput, object objInput)

right? So, right away, a new string is created, along with a reference to the object.

Now, the code, would have to first find the starting and ending brace and pull out the formatting codes. Then, it would have to take the object and apply the formatting code to it and then return the part of the string before the brace, the formatted code, and the part of the string after the brace. In other words, if you had passed it "format {0} me", the return would look like:

return left(strInput, startingBraceIndex) & Format(objInput, formatCode) & right(strInput, strInput.Length - endingBraceIndex - 1)

or something like that. Of course, it is (hopefully) optimized a bit, so that it's not creating as many copies, but still, wouldn't more memory have to be used for the Format method, plus more processing cycles because or what all has to be done...whereas the second routine is much more straightforward.

As far as performance, I just don't see how the first is more efficient than the second. I also don't see how the first is more readable...even with more parameters, you would have to know what was in each spot in the array, so as far as readability, the second would be more readable as well.

Is

object[] objArray = {devNr, idNr, testNr};
return string.Format("Device #{0}, ID#{1}, Test#{2}", objArry);

really more readable than:

return "Device #" + devNr + ", ID#" + idNr + ", Test#" + testNr

?

Sure the first one is a bit cleaner, but IMO, it's not more readable.

Besides, whatever happened to Occam's Razor?

Łukasz Nowakowski29-Jun-10 8:23

Łukasz Nowakowski

29-Jun-10 8:23

Interesting point... I was curious, so I checked String.Format with .NET Reflector... Actually it doesn't split string. Under the hood it uses StringBuilder.AppendFormat. Method is quite long and operates on char[] (from format.ToCharArray()). And I'm tired, so didn't trace the method body. Just took a look on it.