Take the 2-minute tour ×

This is a super newbie question, I've been programming for a while, but am just learning OOP. I have a class that works with user input via the C# console.
There are different methods in this class to gather different input sets.

I have another class that takes these input sets and puts them in a database.
What is the best way to pass the input from my input class to my database insert class?

My guess would be:

Array1[] = inputClass.GetParameterSet1();

Is there anything wrong with this or is there a better way to do this? Should I even have two classes (The database class could also take the user input)?

share|improve this question
Can you create an object to represent your data being inserted into the DB? –  Dan H May 10 '10 at 20:29

4 Answers 4

up vote 2 down vote accepted

You should have a "data" class, that represents all of your parameters.

Your GetParameters class should create an instance of this class.

Your InsertDatabase class should accept an instance of this class.

public class Data 
    public string value1 {get;set;}
    // add more properties here

public class GetInputParameters
    public Data GetParameters()
        var d = new Data();
        d.value1 = Console.ReadLine();
        return d;

public class InsertToDatabase
    public void InsertRecord(Data value)
        // database persistance code

Additionally, you could use a generic list to pass more than once instance of the data class, you could use an array, but a generic list is much easier to work with.

share|improve this answer
You haven't told him how to call InsertRecord. Also, he wanted to pass a collection of records, not an individual record. –  Robert Harvey May 10 '10 at 20:22
Bross: Should I have a different data class for different input sets? @Robert Harvey: It's ok, I can figure out how to put the data into a database, I'm mostly concerned with proper class design. –  sooprise May 10 '10 at 20:28
Classes should be nouns/noun phrases not verbs/verb phrases...GetInputParameters should be a method within a class. Same with InsertToDatabase. –  Dan H May 10 '10 at 20:29
Also, wow, adding a data class as in your example is really helping OOP click in my brain. It took me a really long while to understand why OOp is good. Thanks! –  sooprise May 10 '10 at 20:45
Agreed, the naming leaves something to be desired. Proper class/method naming is important, but not the main point I was trying to illustrate. –  Nate May 10 '10 at 22:15

In general I think separating your code out into different layers is a good idea. Right now you have your UI layer (the one that works with console input) and your Data layer (the one that inserts data). That's a good start.

What kind of data are you collecting and then inserting? That might be a good candidate for another class. Let's say it's user info, and a user enters their name, age, gender, etc. Whatever you're collecting it can probably be packaged up into an object. You can then just pass this object along to your Data class. The data class can then digest that information however it needs to.

In your input class:

User user = new User();
//get all user info from console, assigning it to your user object
share|improve this answer
This is what I have currently except, I have it in the form: DatabaseInsertClass.InsertIntoDatabase1(ConsoleInterface.GetData()); Is it good practice to assign the output of ConsoleInterface.GetData() to an object, and then pass that object into DatabaseInsertClass.InsertIntoDatabase1(): User user = new User(); user = ConsoleInterface.GetData(); DatabaseInsertClass.InsertIntoDatabase1(user); –  sooprise May 10 '10 at 21:08
@Soo: You can do it either way. The nice thing about putting the data from GetData into its own user variable first, is that you can check the contents of the user variable during debugging. You can't do that as easily if you're passing the output of GetData() directly into your InsertIntoDatabase() method. –  Robert Harvey May 10 '10 at 21:17
@Soo: Adding the user variable to your code can also make it easier to figure out what is happening in your code, since it makes it clear to the reader of your code what is being passed. –  Robert Harvey May 10 '10 at 21:19
It should also make the data easier to use in other places, like your Data class. You'll be able to get things like user.FirstName, user.LastName, etc, instead of trying to remember what index holds the last name. –  Ryan Elkins May 10 '10 at 21:29

Type safety is the first problem I see with this. A better approach would be to wrap your DB using LINQ to SQL, then simply pass around the business object into an abstracted Save() and Delete() method. That way the actual DB implementation could theorectically be replaced, however your business objects certainly would be of value going forward regardless.

share|improve this answer
He's a beginner. None of this is going to make sense to him. –  Robert Harvey May 10 '10 at 20:26

At least two classes is definitely a good idea. You want to try to encapsulate functionality within a class. In a standard console application, I'd suggest creating a class for console I/O, a class for database access, and a class that will allow them to talk to each other, and possibly manipulate the data (i.e. a service class).

So, your console I/O class could wait for data, then call your service class to save the data, and your service would then call upon your database to save the data.

share|improve this answer
Examples...The OP is a beginner. –  Robert Harvey May 10 '10 at 20:27

Your Answer


