I studied in programming and graduated in 1998... yeah i'm old LOL Long story made short, I never worked in that field, but decided to get back to it to make myself a membership management program.
There is one thing I can't recall about object oriented programming and I'd need help if someone could please clarify a few things for me.
I have a program I'm working on that has a main Windows Form calling on different other forms to perform different actions on a database containing information about a sports center that I own.
After a while working on the project, I realized that a few methods I'm using in my different child forms are exactly the same. For example, if the user enters a first and last name, i often have to find what's the memberID. I just copied the code to fasten the process.... BUT !
I DO remember my teachers kept saying:
"If you need something to be accessed by many, then why should it
belong to someone?"
and I know it's not a good way to program.
My question is: How do I work that correctly? Should I put my method in the main parent form and call it from the others? Is that the right way to do it? Do I just need to use a class containing these methods and then I can call them from anywhere in the app? I'm confused.
Thank you for your time and help.
To solve these kind of issues we have some options:
1. Helper Class: Create Helper class. Make it public, this class will be available for all forms. Now you can use methods of this class in all forms.
2. Static class: Create a static class with static properties. by using this you can access use this property value any where throughout application. Main advantage of this you don't need to hit database again and again to get same record.
Hope this will help you.
Related
After spending the last two years as a C#/WPF/MVVM developer, I recently took over a VB/Winform project at a new company.
I've successfully converted the project to C#. I've been doing a large amount of research, trying to figure out the best methods for this project, but I'm trying to figure out exactly how much refactoring and re-configuring to do.
My issue is this: the previous developer created two huge static classes. There are 30+ forms that are used for a variety of tasks. Each form is called from an event driven by a button click on a "main menu" type of screen. When the program initializes, a function from one of these mega-classes is called that instantiates EVERY form. There are also an incredible number of statics and constants.
I've broken the constants out and created a specific class for them. I'm piecing apart the mega-classes into smaller, more manageable (and responsibility specific) classes, but I've got this incredibly large initialization function that instantiates all of these forms.
Thus, my questions (finally) are these: Is what I wrote above a resource nightmare? Or, is this some sort of normal VB/Winform design pattern that I should keep? Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?
Thank you for any direction you can give me. If I can provide more information to make this more specific, please comment and I will edit.
Is what I wrote above a resource nightmare?
Yes
Or, is this some sort of normal VB/Winform design pattern that I should keep?
Absolutely not. The design of the system is pretty much identical in VB and C#. With some very minor exceptions the difference between the languages is just syntax.
Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?
Yes in theory. The forms should operate just as they would if you were writing in C#. Of course if the original dev liked global state so much there could be all sorts of state lurking between one appearance of the form and the next.
There are a few features of VB that can lead weaker devs astray. The presence of the Module (essentially a static class, but sometimes more convenient) can lure some people into adding much more global state than they should. Also in VB, it automatically creates as needed a single, global instance of each form with the same name as the class. This can cause devs to confuse the form as a class and object - leading to the single instance of a form, rather than constructing and disposing as needed.
I am quite new to programming and want to make sure I am doing things the "industry standard" way as it normally is the best way. I am about to start my second project and had a quick question about how I should design the program. I have thought about it and decided that the program only needs one class to run, the problem I have is if I should use the form class or make another class? I don't know why I think this might be a bad thing, I just feel it could be.
For example is it ok to put my functions into the "public partial class mainForm : Form" class?
EDIT : I think people are confusing me a bit, I simply want to put some buttons on a form and such - should I put all the actual code i.e. functions that do the actual computing within the forms class or should I make another class and then call myClass.function?
I don't think there is any gain from creating class inherited from Form class just "to do things right" (unless you are talking about self-generated code, which in that case inherits from Form class). If there's no point of inheritance don't use it. In case of windows forms if you create new project your form automatically inherits from Form. Don't try to overthink your project, you'll know how to do things right when time comes - it's a matter of experience. Right now, just do as you think you should do, read a lot and make mistakes! You'll learn in time how the project should look like.
So good luck and have fun coding!
WinForm?
For simple utils go with the form, for anything more hardcore I'd recommend starting with a service object that configures and glues things together. Then you can do:
Application.Run(applicationObjectThatIMadeEarlier.InitialForm);
To get back to where you're used to being.
WinForm constructors can be iffy because of the form designer requirements (it runs the ctor) so its nice to keep things out of the constructor of a WinForm so the form designers keep working.
Generally spoken, yes. As long as you only have one class - in this case your form - and the functions won't be required anywhere else outside of the form.
Is it good practice? Well, not really. Sooner or later you'll be working on projects that don't consist of one class or one form and you'll be sticking all your functions in your form, only to figure out later down the line that you'll need them elsewhere too.
In this specific case you could do it, but I'd personally recommend you to put them in their own class(es).
This is more of a theory based question. I am working on the design for my final project in C#, which is to create Jeopardy. My question is, what would be the best way to pass data between them? For instance, the rubric requires the game opens with an options screen after the splash shows. Here, they will select the number of players and their names. I know that in my gameform load event, I can just specify those things as parameters and pass them as arguments from the optionsform. This seems messy though, is there a more efficient way to create project wide variables that I could reference no matter the form I am currently using?
Thanks for any answers, it's always appreciated!
-- Young Padawan Coder
How about creating a separate business object (i.e. class) with either static properties or singleton pattern. You would then store all your application values there and you can refer to them from anywhere in your application without the messy work of passing around variables all over the place.
What are the best way to store variables in a silverlight application?
Need to transfer store a customer ID throught the application but im not sure what is the best way
Disclaimer: This is a purely subjective answer. Others might object or have better suggestions.
I work mostly in VB.NET and over there, we've got the My.Application namespace where we can keep global variables. VB.NET users also have the option of using a Module for such purposes.
A Module, if I remember right, is equivalent to a static sealed class in C# so you can essentially do something of that sort.
To replicate VB.NET's functionality when I work in C#, I create a static class, with access level set to internal so its members are accessible from within the entire application.
Thus, when I assign a value to a member of the static class, it is accessible from all other classes in the application.
Hope this helps
Store the variable in a place where those things that need to get to it, can; and those things that don't need to get to it, can't. Can't say anything more specific without more information.
If you were following an MVVM pattern then I would have said as a property of the Customer model, with an instance of the customer model being accessed via the ViewModel.
Even if you aren't I would say within the application code and use binding where its needed in the UI. Otherwise you run the risk of changes to your UI causing the loss of customer ID storage at somepoint in the future.
If needed in more than one place then just create a repository that stores all of your data and have that accessed as needed (this way you can decouple your UIs from each other even if they use the same data source.
You may look at using InitParams, without knowing the situation I can't say much more.
http://msdn.microsoft.com/en-us/library/cc838255(VS.95).aspx
This is my first winform app in .NET... I have made a couple of ASP.NET app...
In this app, I have some common variables, like current user name, his selected process etc.. etc.. This should be made accessible from all forms in the app at any time... How could I do this... Is there any place like "Session" in ASP.NET here...
Further How do coders generally pass information from one form to another... Here I want to pass on the info I acquired in the first form to the subsequent forms... I use constructor overloading and pass the values as parameters... I'm pretty sure there has to be a better way to do it...
Thanks for your time...
You might want to implement a Singleton object
Implementing the Singleton Pattern in C#
This is typically used for thread safe code, but will also allow you to access the same instance from multiple forms, allowing you to use the same data without having to pass the object around from form to form.
There are quite a number of ways.
Static objects - These are shared accross applications so you can access them from any form or class. This is not advised by many and singleton classes are preferred, but I dont find any problem with these in winform applications.
Public Properties - These are form specific rather than global. Pretty much similar to ASP.NET usage.
Project Settings collection - This can be used to store data that might not change during the application lifecycle. All the forms can access this.
I'd use singleton in this case, checkout this generic singleton implementation.