strange NullReferenceException

[Red Head]

I have a singleton class DataAccess containing al methods that interact with the DB

This works just fine but when i use this singleton class in a usercomponent and then add my usercomponent to a form, i get an alertbox with a nullreference exception

in my user component

 dgvArtikels.DataSource = DataAccess.getInstance().getArtikels().Tables[0];

in DataAccess

         public static DataAccess getInstance(){
            if (instance == null) 
                instance = new DataAccess(ConfigurationManager.ConnectionStrings["MySQL"]);
            return instance;
        }

        private DataAccess(ConnectionStringSettings connString){
            this.connStringSet = connString;
            factory = DbProviderFactories.GetFactory(connStringSet.ProviderName); //THIS CAUSES THE ERROR
            
        }

what I'm i doing wrong ?

[Red Head]

I have a singleton class DataAccess containing al methods that interact with the DB

This works just fine but when i use this singleton class in a usercomponent and then add my usercomponent to a form, i get an alertbox with a nullreference exception

in my user component

 dgvArtikels.DataSource = DataAccess.getInstance().getArtikels().Tables[0];

this piece of code is executed in the contructor of the UC
if i leave it i can add the UC to the form
and in the constructor of the form i then call the method which caused the error

very strange is this some kind of bug?

[Plater]

I am not sure you can add contructorless objects to forms as components.
A static class yes I think you can, since there is a public constructor.

I never really understood the way singleton was setup in favor of just a static class.

[Red Head]

I never really understood the way singleton was setup in favor of just a static class.

I use a singleton when i shoud be able to access the class anywhere in my project and if the class shoud remember some data (that can change)

I use a static class when i just have methods that calculate or do something and don't have to 'remember' data

I guess this is the right approach, correct me if i'm wrong :)

[Plater]

I dunno, static classes are completely capable of "rememberin g" data too. Not sure what the "School of thought" is for using statics vs singletons, but I personally would choose statics. Less work to setup.

[Plater]

Correct me if I'm wrong, but I thought that singleton classes have private constructors?
-Frinny

A private class would not be accessable to the form trying to instanciate it as a component though would it :-P

[Frinavale]

A private class would not be accessable to the form trying to instanciate it as a component though would it :-P

;) I deleted that post after I looked at his code again ;)

But anyways, I just learned about the Singleton pattern...I've been using it in many of my projects but never knew there was a pattern for it. I'm still not 100% on the exact pattern.

(I'm looking for a good .NET Patterns book...)

[Plater]

Software patterns were the biggest waste I learned in college.
I refuse to use them, and the other software guys who've been doing this stuff for like 20+years have never even heard of them.

[r035198x]

I use a singleton when i shoud be able to access the class anywhere in my project and if the class shoud remember some data (that can change)

I use a static class when i just have methods that calculate or do something and don't have to 'remember' data

I guess this is the right approach, correct me if i'm wrong :)

Use a singleton when you want only one instance of an object to exist at any time in your program.

The static class use part is fine with me.
Coming back to your problem, pinpoint the line that's causing the null reference by using Console.WriteLi ne statements. You can use those to get which variable is null too.

[r035198x]

Software patterns were the biggest waste I learned in college.
I refuse to use them, and the other software guys who've been doing this stuff for like 20+years have never even heard of them.

Then you either actually are using them or writing the same codes over and over again.

[Plater]

Then you either actually are using them or writing the same codes over and over again.

Well if you consider static classes to fall under the singleton then yes.
And with basic concepts like "bridge" and adapter and stuff then yes.
But other then that I still find them silly and product of over-documentation. (UML is obnoxious)

[Frinavale]

Well if you consider static classes to fall under the singleton then yes.
And with basic concepts like "bridge" and adapter and stuff then yes.
But other then that I still find them silly and product of over-documentation. (UML is obnoxious)

I like UML.
I haven't found anything better to outline/describe the solution to my problems yet.
Sometimes it seems to be a bit over kill, but at the same time you know for sure that with that amount of detail there is little room for ambiguity or confusion.

I think that some Requirements Specification Documents can definitely be termed as "over documentation". .. if RSD's are paired up with a nice UML/Use Case type project plan, then I think that over documentation in both areas could be avoided.

-Frinny