CODEWITHSUNDEEP
c#oopclass
sooprise
sooprise

Reputation: 23187

Class Design Question

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

Upvotes: 1

Views: 218

Answers (4)

Ryan Elkins
Ryan Elkins

Reputation: 5797

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

Upvotes: 1

Robin
Robin

Reputation: 1022

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.

Upvotes: 0

Keith Adler
Keith Adler

Reputation: 21178

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.

Upvotes: 0

Nate
Nate

Reputation: 30656

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.

Upvotes: 2

Related Questions