• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 195
  • Last Modified:

Organizing my solution and planning for expansion....vb .net

This seems to be a question a 2 year old might ask, but for a lack of knowing where to look for these answers, I am asking it here.

This pertains to VB .Net 2005 Express Edition. This is a Windows Form Application.

I am working on a program. This program will access a database occasionally, write/read to files, contain multiple forms but doesn't have a Multiple Document Interface, and do several other things that would be a seperate category of thought altogether. When the program starts, I need to check a settings file. If it exists and has data, I will load my Primary form where most of the program tasks are performed; otherwise, I will need to display a Settings form to get this data from the user.

How do I organize my solution? Where should the above logic go in the code? How do I provide a common sense structure to my project so that Database functionality is contained in an object or group of objects seperate from the business code and the interface code?

I know this is a mouthful and not all that clear cut. Any help you experts can provide would be invaluable. I would rather rebuild my program now than to have it become some sort of hideous progeny that controls me.

Thanks again!

  • 3
1 Solution
Bob LearnedCommented:
I don't think that 2 year olds know much about business code and interface code, so I wouldn't worry about the apparent simplicity of your question.

Questions and musings that may or may not be too complex to understand:

1) Model-View-Controller - define a class that identifies the data model, and a form that interacts with the data class with events

2) Data Access Layer - define a class that talks to the database, retrieves data and updates the database

3) Business Rule Layer - define a class that has the validation code for valid date

4) How much do you need to know?  

5) What type of file access are you talking about?  Text files?  XML files?  Excel workbooks?

6) What is the database type?  Are you going to change that in the future?

jbaisdenAuthor Commented:

1) I'm familiar somewhat with the idea of the Model-View-Controller architecture. I understand, or think I do, the theory behind it, but it's the implementation that is eluding me. Could you elaborate on "a class that identitfies the data model, and a form that interacts with the data class with events" section?

2) I get this part. Have a class or set of classes solely responsible for anything having to do with database interaction. I.E. Saving, Inserting, Updating, Getting data.

3) Using forms and such, this seems to be built into each form's class itself. Is this bad? It does seem to make the code more difficult to manage.

4) I would say a good amount more. My biggest pinch is this: I have to set a form as the startup form, but I also have to do validation that might mean I need to display a different form. Rather than just throwing in the validation in my default form, I'd rather have a kind of dummy class and/or Form that I start from and it would be here that I put all validation that would control what forms are shown and hidden. If I do this as a module, the [form].show commands work, but the program exits too quickly (i.e. Runs the code that gives the command to show the form, but then heads right for the end sub as opposed to waiting or something like that).

5) Right now, for simplicity, we are talking about txt files. In the future this will either be xml. This point is quite as important to me as the rest.

6) The only database type i'm using is SQL 2005 primarily. I would like to make it work with both SQL Server 2000 and SQL Server 2005 if possible.
jbaisdenAuthor Commented:

Doesn't anyone have any advice on this topic? Surely, there are some software engineers out there that have been through this process...

Like I said, any help what-so-ever would be greatly appreciated!
jbaisdenAuthor Commented:
No one has anything to say about this?

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now