+1  A: 

Do You have any document specifying what the application is going to do instead of a specification how thing are going to be done?

If you don't have that, then take a step back and write a Functional Specification. After you have that you might want to redo some of the work you already did.

You also should take a few moment's to think how are you going to ogranize your code. What namespaces and classes are you going to use. Where will you put the code for:

  • User interface
  • Business logic
  • Database access

You should isolate those parts of your application to make it easier to maintain.

Michał Piaskowski
Michal, thanks for the reply. I have functional specifications already. I used them to plan the table structure and relationships. Also, in my reading I found I should make sure to keep the UI and business logic separate, however I must admit I really don't know exactly how that will be accomplished due to my inexperience with building a program of this type from scratch. I guess that is a little further down the road for me.
ChrisC
You should avoid what Shaun described as "drop that there, double click and write code". Don't put data access and business logic code in event handlers. create a separate namespaces and classes where you'll put all of that. Then you can call that code from event handlers
Michał Piaskowski
Thanks. So the UI's event handlers will call "interface" classes/namespaces that, themselves, call the business logic?
ChrisC
A: 

I'm not desiring to become a programmer with varied and marketable skills, so I'd rather avoid spending time learning things that won't apply to this project.

In that case, skip .Net. It'll take you time to learn it well enough to do a good job. Since you mentioned you have (perhaps minimal) C++ experience, I'd maybe use Qt instead with the aid of Qt Designer to layout the GUI. From that point the rest of the app should be much like the stuff you've already done.

Unless you know what your doing with .Net, you'll end up with wildly unmaintainable code very, very quickly. I blame Visual Studio for this. By default, it encourages a "drag this thingy here, drop that there, double click and write code" approach to coding that usually results in a horrendous mess.

If you insist that you want C#/.Net anyway, I encourage you to start at the backend and work your way forward. Take the time to model your entities and your data access and your business layer before you even think about GUI. You may even take this a step further and write two project. One would be your dll, containing business and data access logic. The other would be your executable, where you wire your UI events into the dll's api.

Good luck.

Shaun
That sounds good. I chose C# because I might want the option to sell the program one day, and from what I could tell C#/.NET would make installation easy (relatively, at least) for non-technicals on unknown Windows machines. Also I think I found that the licenses applicable would allow commercial use and private code. I briefly glanced at Qt and now I've forgotten what my reason was for not choosing it, and being new to most of this, it's possible I chose wrongly. What do you think?
ChrisC
The Qt license is LGPL, which doesn't preclude commercial possibilities. You really shouldn't have a problem with easy installation either. That said, I wouldn't have to nudge you in a direction you dont _want_ to go. C# with Click Once deployment is attractive indeed if you intend to target a Windows-only audience. Qt would open up commercial opportunities on other platforms. In the end, it really comes down to what you want.
Shaun
That downvote needs justification. I recommended the OP stick with something familiar. My guess is it was downvoted either because your a C++ hater or a .Net fanatic. Both are unhealthy views, but note that I _did_ give good .Net advice.
Shaun
Upvote from me for your help. I'm re-reading your last comment and making sure to understand it as well as I can.
ChrisC
Thanks. To be fair I pretty much zeroed in on the "maintainable" part of your question and made that the basis for my answer. This is what I had in mind when I suggested Qt Designer as well as starting from the back and working forward.
Shaun
I see. So, for maintainability's sake you were suggesting that Qt Designer makes it more intuitive to keep the UI separate from the business logic? If so, if I concentrate on doing this then Qt loses some advantage for me over C#/VS? Thanks again.
ChrisC
+2  A: 

My suggestion to you is to first write your first prototype as a console/text program under the platform of choice. When you've got the input and output the way you want it - then ask again for refactoring help in getting the UI the way you want it. You can also get your db queries easily tested and you're using your existing skills more efficiently earlier on to get the functionality right but with a limited UI.

Your console program will then also be a verification that the GUI version of your program is working as expected.

Edit: Here is a simple program that reads a value from the database and puts it on the screen.

using System;
using System.Data;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        using (SqlConnection connection = new SqlConnection("Data Source=server;database=mydb; Integrated Security=SSPI"))
        {
            SqlCommand command = connection.CreateCommand();
            command.CommandText = "SELECT CategoryID, CategoryName FROM dbo.Categories;";

            try
            {
                connection.Open();

                SqlDataReader reader = command.ExecuteReader();

                // process each row one at a time
                while (reader.Read())
                {
                    // reader contains the row (reader[0] is first column, etc)
                    Console.WriteLine("\t{0}\t{1}", reader[0], reader[1]);
                }
                reader.Close();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
    }
}

Use this (and the link from where I got another version of this) to help you through through ado.net initially. As an experience programmer you can see that if you follow this model you can create common functions that return data based on passed in queries. When you want to get tables of data back instead of simple values, I'd suggest moving from ExecuteReader to other data functions functions.

N.B. Generally I wouldn't suggest you start here - I'd suggest fluent NHbernate but that is bit more complex for a beginner and would be better after you understand the relationship your code (in .net) has to the DB and the data therein.

Also jsut had a thought. If you want to use another technology rather that SqlClient you can use Linq2Sql. Watch this video to see if its helpful.. In fact there are some very useful free videos on DimeCasts.net.

Preet Sangha
Thank you, Preet.
ChrisC
+1  A: 

Starting a new answer cause my old doesn't apply to these very specific steps. This answer is in support of Preet Sangha's reply, but is intended to be more specific than any of us have yet been.

Start a console app and add a "using System.Data.SqlClient" line at the top of the app. You'll need to start with a Connection object, then a Command object. Experiment with executing queries using your command object. Try both an "insert" statement and a "select" statement. For the "select", you'll be getting something back from the database. Use a SqlDataReader (executeReader on the command) for this and experiment with pulling values out (reader.read() & getXXX where XXX is the type of data you want to retrieve). These should make you comfortable enough to get your arms around the problem and return with a more directed question.

Given how new you are to this, MSDN will be your best friend. This should help get ya started :) http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection%28VS.71%29.aspx

Shaun
Thanks. So next I should 1) download and install my SQL db software, 2) set up my tables and put data into them, 3) write the console code and 4) start playing with queries?
ChrisC
Unless your using the "express editions" of visual studio (and maybe even then but I don't know), you should already have a database server avaialable. Sql Express would have been installed when you installed VS. Yes to the rest.
Shaun
Also, I'd be more than happy to help with next steps after that, but I think this is where you should start...
Shaun
Thank you. In VS 2008 Pro, I created a db under the Visual C#. It took me through the steps of creating a connection and naming the db, but I don't see the db itself or how to create tables. Can you tell me how to do what I should do to get going?
ChrisC