[trialanderror]

Hello All,

I am a self-taught programmer. I have been coding in VB for probably 6 years now, but have been devoted 100% for the last year. As the applications I am writing get larger and more complex, I am always trying to keep them as efficient as possible, but still always end up with a lot of spaghetti code.

What I am having a hard time with is the architecture of my windows forms applications. I have tried to find resources related to the 'best practices' but cannot find much that really helps me understand. I am trying to stick to the Logical N-Tier approach but I still have a lot to learn. The application I am currently working on is pretty complex and interfaces with multiple web services and MySQL databases. With this, I am finding it difficult to keep all my code in order.

I have two questions for anyone who will listen: First, how do you know what code to put on the form and what to seperate out into another class or module? How much seperation is too much?

Secondly, does anyone have any good references they have used to help understand proper application architecture?

This post has been edited by AdamSpeight2008: 16 November 2011 - 03:22 PM

[Beach_Coder]

Great question.

[xnn]

Sounds like you are using a procedural strategy when you approach your problems. Honestly it sounds like you would benefit from any Object Oriented book. Once you become more familiar with encapsulating logic in objects you will be off to a good start to learn layered architecture.

Books:
http://www.amazon.co...21319450&sr=8-3

http://www.amazon.co...1319450&sr=8-16

[Beach_Coder]

"Everything is an object." I have to keep reminding myself of that.

I thought your question was great because I have the same problem. Self-taught. I repeat the same cycle. Something I'm working on turns into a monster and it becomes a hot mess.

I hope there is no objection; I'd like to piggyback on your question.

My hazy understanding, exclusive to using vb.net, of the way to look at is:

1) Every individual calculation or instance of doing something should be in its own function or sub.
2) Any function or sub in your project that is not absolutely specific to a single form should be in a module.
3) Functions and subs which are specific to a single purpose should be in the same module.
4) Any group of related "things" you define and refer to more than once should be in its own class.
5) Any group of forms and modules that don't interact with other forms and modules within a project should be in a separate project within a solution.
6) Any class referred to by more than one project in a solution should be a dll.
7) Any part of a solution that is in a different .Net language should be in its own project.
8) Any group of projects that an exist on their own should be in their own separate solution.

Perhaps someone with an informed command of architecture or someone experienced enough to know which sort of design operates most efficiently or most reliably in an uncontrolled environment (I am thinking of cases where there is interaction or just contact between one application and any external object (such as a website or external server) or in a client-server environment (where any given application operates but for the grace of the guy in charge of the lan and all things are vulnerable to the impact of a process that someone else within the same client-server environment is running)) can clear some of this up.

[xnn]

Beach_Coder, on 15 November 2011 - 11:43 AM, said:

1) Every individual calculation or instance of doing something should be in its own function or sub.

Perhaps someone with an informed command of architecture or someone experienced enough to know which sort of design operates most efficiently or most reliably in an uncontrolled environment (I am thinking of cases where there is interaction or just contact between one application and any external object (such as a website or external server) or in a client-server environment (where any given application operates but for the grace of the guy in charge of the lan and all things are vulnerable to the impact of a process that someone else within the same client-server environment is running)) can clear some of this up.

Beach Coder, You have basics down. I think putting every single calculation in it's own method might be a little overboard. I like to encapsulate units of work into a method. For instance, If I'm dynamically repositioning a bunch of radio buttons in a panel I will create a method that loops through my radio buttons, positioning the first, then the rest are positioned based on the previously right boundry + some Margin constant. I'm not going to make adding the margin between buttons it's own method, because it's just 1 line of code, it's not redudant, and it's part of the unit of work that I'm trying to accomplish.

No one can tell you which pattern or design is best. Applications are usually a composite of multiple design patterns that fit the unique problem you are trying to solve. There are design patterns that address certain issues, but theres always trade offs.

I found the following books helpful when studying Application Architecture:

http://www.amazon.co...21399859&sr=8-1

http://www.amazon.co...21399879&sr=1-3

http://www.amazon.co...21399896&sr=1-1

http://www.amazon.co...21399913&sr=1-2 <-- very good intro to design patterns.

[trialanderror]

xnn, on 15 November 2011 - 04:38 PM, said:

Beach Coder, You have basics down. I think putting every single calculation in it's own method might be a little overboard. I like to encapsulate units of work into a method. For instance, If I'm dynamically repositioning a bunch of radio buttons in a panel I will create a method that loops through my radio buttons, positioning the first, then the rest are positioned based on the previously right boundry + some Margin constant. I'm not going to make adding the margin between buttons it's own method, because it's just 1 line of code, it's not redudant, and it's part of the unit of work that I'm trying to accomplish.

No one can tell you which pattern or design is best. Applications are usually a composite of multiple design patterns that fit the unique problem you are trying to solve. There are design patterns that address certain issues, but theres always trade offs.

I found the following books helpful when studying Application Architecture:

http://www.amazon.co...21399859&sr=8-1

http://www.amazon.co...21399879&sr=1-3

http://www.amazon.co...21399896&sr=1-1

http://www.amazon.co...21399913&sr=1-2 <-- very good intro to design patterns.

Thank you for both your replies. I guess, my biggest obstacle is actually getting into OOP. I get the whole, 'A Person is a type of Human" thing, which I can use when making actual objects (IE Creating a new line to insert into my DB) but what about when I am dealing with things that aren't quite 'objects'?

Here is an example: My application loads up. The user clicks 'Run' to hit a webservice and return all relevant data to that user. That information is stored in a dataset and displayed to the user in a datagridview. There is logic run on the data to insert and highlight certain things along with some visual color coding. Lastly, they can click on an item in the DGV and it will query a MySQL DB for information related to that item.

Behind the curtains: Clicking run calls a DLL that holds all webservice information, that kicks an XML to the 'Run Sub' (because that is where the click originated). The 'Run Sub' calls a module to process the xml into a global Dataset. That module calls another 'logic' module to process all the data. Finally the 'Run Sub' sets the DGV Datasource to the dataset. If an item is clicked on DGV, it is passed off to a module that handles all SQL.

My issue is that I think I am running to much on the Form items (A lot is held in the 'Run Sub'). I know it is hard to follow this pseudocode, but if you can maybe you guys can give me some pointers. I will look at those books today, thank you for posting those.

[modi123_1]

Quote

I have two questions for anyone who will listen: First, how do you know what code to put on the form and what to seperate out into another class or module?

It sort of depends on your point of view. Something like the MVVm (model, view, view-model) the only code in the form itself is base level GUI interactions. Everything else is handled in the abstracted layers behind it. It's a pain in the ass frankly, but I try and keep the principle alive.

In the business-ie side it becomes a bit easier with what data goes together. Each app tends to need a set of data passed around and you just work with that boundary.

Quote

How much seperation is too much?

When the code becomes hard to follow, maintain, or understand. Remember objects are supposed to help ease maintenance and re-usability of your code. If you find yourself in a horrible mess then you know you've gone too far and should start over.

Quote

Secondly, does anyone have any good references they have used to help understand proper application architecture?

I believe the books given are a good place to start. I would figure you degree track would toss a class in there for you.

[Beach_Coder]

I try and keep anything that can live on its own separate and group with it the smaller things which need the living thing to work together with it. With your form comprised of a button and datagridview, the sub that handles the click event calls a separate sub within that form's code. That sub calls a sub in a separate module. This sub, the module's primary sub if you will, is comprised only of calls to servant subs in the same module. Servant sub one would be calling the dll. The dll returns the XML to the primary sub which then calls servant sub two to populate the dataset with the XML data and returns it to the primary sub. Servant sub three is then called to apply to processing logic to the dataset. The fully processed dataset is then returned to the primary sub, which having served its purpose, returns the fully processed dataset to the sub on the form that called it. That sub will then call a servant sub within the form to feed the logically processed data to the DGV. When the user clicks on data in the dgv, the click handler call a sub within that form which calls a sub in a second module that deals with the SQL bit.
I apologize if this is messy to follow. Another way to look at it is to contemplate having multiple forms that generally do this same thing (call a webservice and display data to the user who can then interact with that data) with multiple webservices available to each with multiple datasets. Whatever is absolutely unique to any given form, keep with the form. Whatever code that is commonly useful to each of these unique forms should be in its own separate package. Then break that down again among code that serves a unique purpose and code that is commonly useful. All of this is done in a way that survives the common sense test. As xnn suggested, don't go crazy and put literally every method into its own sub or function and every sub in its own module and every module in its own project and so on. However, once you reach a point with a pageful of code where you get lost looking for something that's a sign that there's maybe too much going on in one place.
Also, having a lot of things happening with webservices and data going back and forth and data being processed has serious implications in a large-scale environment. Efficiency, avoiding resource conflicts, and accounting for the bad day when the train goes off the tracks somewhere within your network infrastructure need to be considered; doing so effectively is presently well beyond my own capabilities however.

[trialanderror]

Beach_Coder, on 16 November 2011 - 01:41 PM, said:

I try and keep anything that can live on its own separate and group with it the smaller things which need the living thing to work together with it.

Thank you guys for the responses. This is all good advice, I appreciate it.