none
Need help with application design RRS feed

  • Question

  • I'm very new to VB and programming in general, having previously only written a few macros using VBA in Excel and then built a simple application from a "teach yourself" book on VB2008 so if you can go easy on my lack of knowledge that would be most appreciated!  Having said that, I'm probably jumping in too deep with my proposed application!

    I am trying to build an application that will effectively do the job of 3 Excel spreadsheet calculations to make them more user-friendly, more professional looking and more robust, as well as allowing data from each calculation to transfer between the others more easily.  The calculations relate to design of acoustics in buildings, namely:

    1. Noise from traffic etc outside through the building facade to inside rooms of the building;

    2. The amount of "echo" within a room; and

    3. Sound transfer between rooms through walls/floors.

    I have been able to set up forms for each calculation referencing back to Arrays to look up information relating to losses through different types of constructions, etc and then taking the selected construction/sizes, etc and putting them into variables, which are then looked at to fill text boxed on the form with a relatively complex calculation using logs etc automatically updating depending on the filled text boxed.

    I anticipated the application being an MDI type.  Using the toolstrip or menu bar a user could then add a new calculation of one of the three types.  This would then call up a new version of the relevant form as a child within the MDI parent which the user would be prompted to "name".  The MDI Parent would have a tree-view to the left hand side, where each time a new form is loaded then the name is added to the list ("Office 1 - Facade Insulation", "Office 2 - Partition Sound Insulation", etc).

    The problems I am facing and need help with are:

    1. Is it going to be simpler to put the information into a database rather than creating multiple versions of each form which wouldn't be able to be disposed as the information in them would need to stay live so they could be recalled?  I haven't had any experience using a database as yet, so had hoped I could do without it, but the more I get into this the more I think I'm going to have to bite the bullet and learn how to use them.

    2. If I do have to use a database, what would be the easiest one for a relatively simple application such as this?  The database would have to be "project" specific such that when a new project is created a new database is created, and when a user saves and then closes a project that database is saved and closed, and then a new database created when the user then selects File > New from the menu, etc.

    3. I will need to be able to save the calculations to a project specific directory and then open or create a new unrelated project as each file would be for a different site; if you imagine one project may be in London and another in Manchester, therefore the calculations associated with one site need to be in a different file to any other.  How can I package up all the information for one site into a "saved file".  Unfortunately the "teach yourself" guide simply shows how to save a .txt file; how do you decide what file type you need to use and how do you package everything (e.g. either the information in all of the forms or the background database) into a single file that can then be opened when needed via the application?

    Finally if it may help the application would be run on individual computers, does not need to connect via the web, etc, and don't need to worry about multiple people having a saved file open at the same time.

    Many thanks for any help in advance.

    Saturday, June 2, 2012 1:45 AM

Answers

  • 1.Not necessarily into a database, but definately into some sort of data structure that allows the data items to be easily manipulated within your application.  Transferring the data between the application objects and the database is relatively easy becasue the objects will probably have a similar structure to the database stucture.  Doing it like this also helps to separate your application code from the technology you choose for saving the data that the code uses, so you are not dealing with two new complexities at the same time. But the structure that you use within the application should be designed before the database where the data will eventually be stored, and that's where classes and objects come in.

    You should use the database as a repository rather than as your working storage wherever possible.  That is, retrieve your data into your objects, do whatever you need to do in terms of user interaction, calculations and displays, then put the data from the objects back into the database.  

    2. You would not typically create a new database for a new project.  You might do that if portability of the data by project was necessary, but usually the project ID would be a key by which all data relating to that project is distinguished from all other data in the database relating to other projects.  If you want to maintain project data as separate files or separate sets of files, you don't actually need a formal database.

    3. See comments above.  Your queries here assume that you will not be using a combined database and that your data will be in separate files.  Organising thse files by folder is possible, and relatively simple, but might not even be necessary - you could easily organise by using a file naming convention, or just putting everything into one file.  Plain text files are a simple option, and may be suitable for simple data storage requirements.  If you make the separation between application objects and data storage that I propose, you can change your data storage choice with very little trouble at any time.

    If you start by concentrating on your object design for the application, instead of your data storage, your data storage options might become obvious during that development, and you can choose what is most apprpriate as the need arises.

    As you do not require multi-user access, virtually any data storage option is available.

    Saturday, June 2, 2012 3:08 AM
  • Acamar's insight is very helpful and great.  His point is at the database and the storage of your application data aspect.  Here IMO, I wanna point out that you'd better lay good foundation on Object Oriented concepts and techniques such as these terms about Class, Object, Instance, and the main pillar of OO spirits such as 1.Encapsulation 2. Inheritance 3. Polymorphism(there are two flavors of them--one is method overloading and the other is dynamic binding.) 4. Abstraction.

    Because you spoke of creating similar forms to fill in the MDI main form, in order to achieve this, you must be very familiar with the underlying Inheritance mechanism of OO in your programming language.  In addition,  your project is win form style.  I personally suggest you also proceed to read some subjects about win forms at the same time.

    That is it.  Hope it helps.


    My blog: http://soho-hsh.blogspot.com

    Saturday, June 2, 2012 9:46 AM
  • On 6/1/2012 9:45 PM, RobCant wrote:
    > I'm very new to VB and programming in general, having previously only
    > written a few macros using VBA in Excel and then built a simple
    > application from a "teach yourself" book on VB2008 so if you can go easy
    > on my lack of knowledge that would be most appreciated! Having said
    > that, I'm probably jumping in too deep with my proposed application!
    >
    > I am trying to build an application that will effectively do the job of
    > 3 Excel spreadsheet calculations to make them more user-friendly, more
    > professional looking and more robust, as well as allowing data from each
    > calculation to transfer between the others more easily. The calculations
    > relate to design of acoustics in buildings, namely:
    >
    > 1. Noise from traffic etc outside through the building facade to inside
    > rooms of the building;
    >
    > 2. The amount of "echo" within a room; and
    >
    > 3. Sound transfer between rooms through walls/floors.
    >
    > I have been able to set up forms for each calculation referencing back
    > to Arrays to look up information relating to losses through different
    > types of constructions, etc and then taking the selected
    > construction/sizes, etc and putting them into variables, which are then
    > looked at to fill text boxed on the form with a relatively complex
    > calculation using logs etc automatically updating depending on the
    > filled text boxed.
     
    Those forms should be as dumb as possible with all business logic kept
    out of the forms a separation of UI and business and possible database
    logic kept out of the form.
     
    >
    > I anticipated the application being an MDI type. Using the toolstrip or
    > menu bar a user could then add a new calculation of one of the three
    > types. This would then call up a new version of the relevant form as a
    > child within the MDI parent which the user would be prompted to "name".
    > The MDI Parent would have a tree-view to the left hand side, where each
    > time a new form is loaded then the name is added to the list ("Office 1
    > - Facade Insulation", "Office 2 - Partition Sound Insulation", etc).
     
    You don't make any since here. The forms should be generic enough that
    it doesn't matter what user is using the forms or what office the user
    is from. The forms should be data agnostic.
    >
    > The problems I am facing and need help with are:
    >
    > 1. Is it going to be simpler to put the information into a database
    > rather than creating multiple versions of each form which wouldn't be
    > able to be disposed as the information in them would need to stay live
    > so they could be recalled? I haven't had any experience using a database
    > as yet, so had hoped I could do without it, but the more I get into this
    > the more I think I'm going to have to bite the bullet and learn how to
    > use them.
     
    Yes, the database path is the best approach.
    >
    > 2. If I do have to use a database, what would be the easiest one for a
    > relatively simple application such as this? The database would have to
    > be "project" specific such that when a new project is created a new
    > database is created, and when a user saves and then closes a project
    > that database is saved and closed, and then a new database created when
    > the user then selects File > New from the menu, etc.
     The database tables would be generic so that it would not matter what
    user saved data to the database, because data in any table would be
    linked to a user instance of the user's data in the database.
     
    >
    > 3. I will need to be able to save the calculations to a project specific
    > directory and then open or create a new unrelated project as each file
    > would be for a different site; if you imagine one project may be in
    > London and another in Manchester, therefore the calculations associated
    > with one site need to be in a different file to any other. How can I
    > package up all the information for one site into a "saved file".
    > Unfortunately the "teach yourself" guide simply shows how to save a .txt
    > file; how do you decide what file type you need to use and how do you
    > package everything (e.g. either the information in all of the forms or
    > the background database) into a single file that can then be opened when
    > needed via the application?
     
    You could take the data for a user instance in the database tables and
    dump it to a XML file type, which is string data type that has a structure.
    >
    > Finally if it may help the application would be run on individual
    > computers, does not need to connect via the web, etc, and don't need to
    > worry about multiple people having a saved file open at the same time.
     
    Well, the front end the UI can be a Windows desktop solution, but the
    backend where the database logic is kept, you would need to come over
    the Internet to interact with the database, but that does not make it a
    Web based solution, but the backed could be Web based to keep things
    centralized. One database access point for all users.
     
    Other than that approach in the design of the application, I see a total
    nightmare for you.
     
    You may want to look at .NET WPF and MVVM, which can be used in a
    Windows desktop application and keep business logic and database logic
    out of the forms.
     
    Saturday, June 2, 2012 11:54 AM

All replies

  • 1.Not necessarily into a database, but definately into some sort of data structure that allows the data items to be easily manipulated within your application.  Transferring the data between the application objects and the database is relatively easy becasue the objects will probably have a similar structure to the database stucture.  Doing it like this also helps to separate your application code from the technology you choose for saving the data that the code uses, so you are not dealing with two new complexities at the same time. But the structure that you use within the application should be designed before the database where the data will eventually be stored, and that's where classes and objects come in.

    You should use the database as a repository rather than as your working storage wherever possible.  That is, retrieve your data into your objects, do whatever you need to do in terms of user interaction, calculations and displays, then put the data from the objects back into the database.  

    2. You would not typically create a new database for a new project.  You might do that if portability of the data by project was necessary, but usually the project ID would be a key by which all data relating to that project is distinguished from all other data in the database relating to other projects.  If you want to maintain project data as separate files or separate sets of files, you don't actually need a formal database.

    3. See comments above.  Your queries here assume that you will not be using a combined database and that your data will be in separate files.  Organising thse files by folder is possible, and relatively simple, but might not even be necessary - you could easily organise by using a file naming convention, or just putting everything into one file.  Plain text files are a simple option, and may be suitable for simple data storage requirements.  If you make the separation between application objects and data storage that I propose, you can change your data storage choice with very little trouble at any time.

    If you start by concentrating on your object design for the application, instead of your data storage, your data storage options might become obvious during that development, and you can choose what is most apprpriate as the need arises.

    As you do not require multi-user access, virtually any data storage option is available.

    Saturday, June 2, 2012 3:08 AM
  • Acamar's insight is very helpful and great.  His point is at the database and the storage of your application data aspect.  Here IMO, I wanna point out that you'd better lay good foundation on Object Oriented concepts and techniques such as these terms about Class, Object, Instance, and the main pillar of OO spirits such as 1.Encapsulation 2. Inheritance 3. Polymorphism(there are two flavors of them--one is method overloading and the other is dynamic binding.) 4. Abstraction.

    Because you spoke of creating similar forms to fill in the MDI main form, in order to achieve this, you must be very familiar with the underlying Inheritance mechanism of OO in your programming language.  In addition,  your project is win form style.  I personally suggest you also proceed to read some subjects about win forms at the same time.

    That is it.  Hope it helps.


    My blog: http://soho-hsh.blogspot.com

    Saturday, June 2, 2012 9:46 AM
  • On 6/1/2012 9:45 PM, RobCant wrote:
    > I'm very new to VB and programming in general, having previously only
    > written a few macros using VBA in Excel and then built a simple
    > application from a "teach yourself" book on VB2008 so if you can go easy
    > on my lack of knowledge that would be most appreciated! Having said
    > that, I'm probably jumping in too deep with my proposed application!
    >
    > I am trying to build an application that will effectively do the job of
    > 3 Excel spreadsheet calculations to make them more user-friendly, more
    > professional looking and more robust, as well as allowing data from each
    > calculation to transfer between the others more easily. The calculations
    > relate to design of acoustics in buildings, namely:
    >
    > 1. Noise from traffic etc outside through the building facade to inside
    > rooms of the building;
    >
    > 2. The amount of "echo" within a room; and
    >
    > 3. Sound transfer between rooms through walls/floors.
    >
    > I have been able to set up forms for each calculation referencing back
    > to Arrays to look up information relating to losses through different
    > types of constructions, etc and then taking the selected
    > construction/sizes, etc and putting them into variables, which are then
    > looked at to fill text boxed on the form with a relatively complex
    > calculation using logs etc automatically updating depending on the
    > filled text boxed.
     
    Those forms should be as dumb as possible with all business logic kept
    out of the forms a separation of UI and business and possible database
    logic kept out of the form.
     
    >
    > I anticipated the application being an MDI type. Using the toolstrip or
    > menu bar a user could then add a new calculation of one of the three
    > types. This would then call up a new version of the relevant form as a
    > child within the MDI parent which the user would be prompted to "name".
    > The MDI Parent would have a tree-view to the left hand side, where each
    > time a new form is loaded then the name is added to the list ("Office 1
    > - Facade Insulation", "Office 2 - Partition Sound Insulation", etc).
     
    You don't make any since here. The forms should be generic enough that
    it doesn't matter what user is using the forms or what office the user
    is from. The forms should be data agnostic.
    >
    > The problems I am facing and need help with are:
    >
    > 1. Is it going to be simpler to put the information into a database
    > rather than creating multiple versions of each form which wouldn't be
    > able to be disposed as the information in them would need to stay live
    > so they could be recalled? I haven't had any experience using a database
    > as yet, so had hoped I could do without it, but the more I get into this
    > the more I think I'm going to have to bite the bullet and learn how to
    > use them.
     
    Yes, the database path is the best approach.
    >
    > 2. If I do have to use a database, what would be the easiest one for a
    > relatively simple application such as this? The database would have to
    > be "project" specific such that when a new project is created a new
    > database is created, and when a user saves and then closes a project
    > that database is saved and closed, and then a new database created when
    > the user then selects File > New from the menu, etc.
     The database tables would be generic so that it would not matter what
    user saved data to the database, because data in any table would be
    linked to a user instance of the user's data in the database.
     
    >
    > 3. I will need to be able to save the calculations to a project specific
    > directory and then open or create a new unrelated project as each file
    > would be for a different site; if you imagine one project may be in
    > London and another in Manchester, therefore the calculations associated
    > with one site need to be in a different file to any other. How can I
    > package up all the information for one site into a "saved file".
    > Unfortunately the "teach yourself" guide simply shows how to save a .txt
    > file; how do you decide what file type you need to use and how do you
    > package everything (e.g. either the information in all of the forms or
    > the background database) into a single file that can then be opened when
    > needed via the application?
     
    You could take the data for a user instance in the database tables and
    dump it to a XML file type, which is string data type that has a structure.
    >
    > Finally if it may help the application would be run on individual
    > computers, does not need to connect via the web, etc, and don't need to
    > worry about multiple people having a saved file open at the same time.
     
    Well, the front end the UI can be a Windows desktop solution, but the
    backend where the database logic is kept, you would need to come over
    the Internet to interact with the database, but that does not make it a
    Web based solution, but the backed could be Web based to keep things
    centralized. One database access point for all users.
     
    Other than that approach in the design of the application, I see a total
    nightmare for you.
     
    You may want to look at .NET WPF and MVVM, which can be used in a
    Windows desktop application and keep business logic and database logic
    out of the forms.
     
    Saturday, June 2, 2012 11:54 AM