Application directories for Form App?
-
I have a kinda hugh client Form Application running and maintaining. It consist of two sub-systems, 1 for marketing and 1 for management. It started as a Management applicaiton, created in VS08, so all classes etc. thats created for the Management sub-system (that was the first), was inside the Project root.... Later when I added Marketing Subsystem, I created a directory in the Project root, named 'Marketing' and afterwards I created every single Class and stuff related to Marketing in that folder. But making folder for sub-systems also means that I have to call Class' and objects from each folder, with the foldername in front. Eg.: Marketing.Customer newCustomer = new Marketing.Customer(); instead of: Customer newCustomer = new Customer(); But is it right or wrong to make those folders for each subsystem, to keep an easy overview of your application? Or should I forget everything about folders in the solution?
-
I have a kinda hugh client Form Application running and maintaining. It consist of two sub-systems, 1 for marketing and 1 for management. It started as a Management applicaiton, created in VS08, so all classes etc. thats created for the Management sub-system (that was the first), was inside the Project root.... Later when I added Marketing Subsystem, I created a directory in the Project root, named 'Marketing' and afterwards I created every single Class and stuff related to Marketing in that folder. But making folder for sub-systems also means that I have to call Class' and objects from each folder, with the foldername in front. Eg.: Marketing.Customer newCustomer = new Marketing.Customer(); instead of: Customer newCustomer = new Customer(); But is it right or wrong to make those folders for each subsystem, to keep an easy overview of your application? Or should I forget everything about folders in the solution?
You could just add Using .Marketing to your using statements. Once you've done that you can just do Customer newCustomer = new Customer(); This way you can have seperate namespaces for Marketing and Management and thus have something of a filter when coding. *Don't punch me for saying 'filter' :~* Or You can just open the class file and remove the 'Marketing' bit next to the default namespace. Try creating a class in the root of the project and then dragging it into the marketing folder, it won't have the Marketing bit. Also: Folders mean organizing and structuring you app, it's almost never a bad idea.
-
I have a kinda hugh client Form Application running and maintaining. It consist of two sub-systems, 1 for marketing and 1 for management. It started as a Management applicaiton, created in VS08, so all classes etc. thats created for the Management sub-system (that was the first), was inside the Project root.... Later when I added Marketing Subsystem, I created a directory in the Project root, named 'Marketing' and afterwards I created every single Class and stuff related to Marketing in that folder. But making folder for sub-systems also means that I have to call Class' and objects from each folder, with the foldername in front. Eg.: Marketing.Customer newCustomer = new Marketing.Customer(); instead of: Customer newCustomer = new Customer(); But is it right or wrong to make those folders for each subsystem, to keep an easy overview of your application? Or should I forget everything about folders in the solution?
-
You beat me to it... :(
I wasn't, now I am, then I won't be anymore.
-
I have a kinda hugh client Form Application running and maintaining. It consist of two sub-systems, 1 for marketing and 1 for management. It started as a Management applicaiton, created in VS08, so all classes etc. thats created for the Management sub-system (that was the first), was inside the Project root.... Later when I added Marketing Subsystem, I created a directory in the Project root, named 'Marketing' and afterwards I created every single Class and stuff related to Marketing in that folder. But making folder for sub-systems also means that I have to call Class' and objects from each folder, with the foldername in front. Eg.: Marketing.Customer newCustomer = new Marketing.Customer(); instead of: Customer newCustomer = new Customer(); But is it right or wrong to make those folders for each subsystem, to keep an easy overview of your application? Or should I forget everything about folders in the solution?
It's probably a little late in the day for you, but this is precisely the type of task that things such as IoC and DI were made for. BTW -when you refer to Marketing.Customer, that's the namespace and classname; Marketing may be your folder, but .NET has no concept of the physical file structure of your project, and uses the namespace instead.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
It's probably a little late in the day for you, but this is precisely the type of task that things such as IoC and DI were made for. BTW -when you refer to Marketing.Customer, that's the namespace and classname; Marketing may be your folder, but .NET has no concept of the physical file structure of your project, and uses the namespace instead.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
IoC? I havn't practically used that pattern yet, but ain't that some kind of Facade/Controller pattern? But after what I see in replys, I guess that making folder in the solutions for keeping subsystems controlled, is a good idea, and may be the correct use depending on size of application? And add the using .Marketing or .Management in the classes, sounds like a nice trick instead of editing 10000 lines of code.