Hey, I am new to C# and object-oriented programming. Object-oriented programming involves creating classes that are used to represent objects in memory. However, in real-world applications you are probably going to want to permanently store data in a database immediately when any new data is added or changed, as to not risk losing it. I guess I'm just confused about exactly how a database should be implemented, how often it should be updated, and if you really should work directly with the database or with an object in memory. Where does the line that separates objects in memory and their existence in the database occur?
For example, I work at a bar that has several pool tables. I am trying to make an application that allows us to keep track of how long someone has been on a pool table, and thus how much money they owe (eg. 5$ an hour for pool time). From what I've learned so far, I would have a Table object for each table that would have attributes such as table number, number of players, start time, etc. All of that would be kept in memory, and any changes would be made to the object in memory. But it's important that if the computer crashes or the program crashes at any given time, that we don't lose the data for each table. So pretty much every time a change occurs, it needs to update the database. My question is do I just work directly with the database, and have no table objects in memory, or do i update the database periodically. What is the best way, in theory, to go about this? I can figure out how to use databases and everything, but i just need a general approach to use throughout my program for when and where i interact with the database.
Thanks in advance for any insight, I've made simple programs that use objects, as well as simple programs that store data in a database, but I've never made a complex real-world app that mixes both.
There are several different approaches you can take. I mean you can even have SQL Server or Microsoft Access running on a pc and periodically manually run some database scripts to update the database to reflect that status of each pool. I wouldn't do it that way but that is an option. Whether a given approach is right or wrong depends on a number of factors. For example if you were a professional developer you would probably want to go for the option that allows you to right the least amount of code (e.g. SQL Server database, Linq to SQL/Entity Framework, Simple UI based WPF databound controls). In your case you're also learning C# and object oriented programming so from that point of view you may choose to do it differently. Since you're learning you may actually do it in different ways. The best way to do it is to start! And you if have any specific problems you can come back to the forum. I would also recommend MSDN and Google (I'm not sure in which order ). There are loads of samples on how to do just about anything. More specifically in your situation I would recommend design a database that looks ok to you. Go for the simples possible application (e.g. you would manually enter the data periodically). Later on you could think of automating the process more...
Thanks for the advice, I guess there are many ways to go about it. I'm leaning towards LINQ to SQL, and every time a pool table is updated or changed I have to update the database. I just have to learn more about data binding and just try making it like you said. Thanks again!
Yeah. For most of the databinding you'll be doing work with Visual Studio designer (I assume you're using Visual Studio). You want to learn how to write good c# code but then once you've learnt you try to write as least amount of code as possible. Often less is more in object oriented development and in programming in general. Hence the recommendation for Linq to SQL, data sources (e.g. LinqDataSource), data bound user interface elements. All the best. By the way I think you've got a good idea. You might be able to roll it out to a few establishments and make a little bit of money for it so put your best into it. (I know the commercial aspect is not the focus of this forum but I thought I'd mention it... )