tags:

views:

145

answers:

4

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();
DatabaseInsertClass.InsertIntoDatabase1(Array1[]);

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)?

+2  A: 

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.

Nate Bross
You haven't told him how to call `InsertRecord.` Also, he wanted to pass a collection of records, not an individual record.
Robert Harvey
@Nate 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.
Soo
Classes should be nouns/noun phrases not verbs/verb phrases...GetInputParameters should be a method within a class. Same with InsertToDatabase.
Dan H
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!
Soo
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 Bross
A: 

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.

Nissan Fan
He's a beginner. None of this is going to make sense to him.
Robert Harvey
A: 

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.

Robin
Examples...The OP is a beginner.
Robert Harvey
+1  A: 

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
DatabaseInsertClass.InsertIntoDatabase1(user);
Ryan Elkins
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);
Soo
@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
@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
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