none
Need vb.net and web application to access the same DB RRS feed

  • Question

  • I am working on a project to automate a transport system, I am using VB.net.  Halfway through the project the client realized that some of the interaction from his clients will be done online. So this will give rise to both a desktop and web application. These two applications will be accessing the same database. I am looking for suggestion on how to do this,   have not been involve in something like this before.  If this is the wrong forum please feel free to send to the right forum. Thank you for your time

    Tuesday, July 31, 2018 6:37 PM

Answers

  • Hello,

    I would suggest (if SQL-Server) looking at hosting your database in Azure and access the data via SqlClient data provider or Entity Framework for client side while it's both work web side depending on how users interact with data yo may need to look at a repository pattern were the controllers work with XML or Json for instance to feed back to the repository. BUT that is high level, more details would be needed to figure out an appropriate architecture. 


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by alobi Wednesday, August 1, 2018 6:10 AM
    Tuesday, July 31, 2018 6:49 PM
    Moderator
  • I am working on a project to automate a transport system, I am using VB.net.  Halfway through the project the client realized that some of the interaction from his clients will be done online. So this will give rise to both a desktop and web application. These two applications will be accessing the same database. I am looking for suggestion on how to do this,   have not been involve in something like this before.  If this is the wrong forum please feel free to send to the right forum. Thank you for your time

    At this point the solution becomes what is commonly known as a "distributed application".

    You will typically place the bulk of your "business logic" (the code that does all of the primary work and calculations) into some form of web service.  This web service will then expose an API that provides various methods for clients to call to execute all of the work, and will contain the only code which accesses the database.  Each client (desktop application, web application) is then little more than an input and display mechanism for calling the methods of the web service.  This allows you to safely access the database from one location and allows all client applications to reuse the same business logic.

    I would highly suggest that you start here: https://www.asp.net/web-api and examine the possible solutions.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Marked as answer by alobi Wednesday, August 1, 2018 6:09 AM
    Tuesday, July 31, 2018 8:58 PM
    Moderator
  • Thanks, this is very very helpful and a good place to start.

    You're welcome.

    The service route is generally recommended over putting data access code into each client program.  It is far more secure because the only code that knows how to access the database is running inside of the webservice, and the webservice code is not available to the end user.  If you put database access code in the client, you have to be very careful not to expose the database connection information and worry about someone decompiling your client and finding the connection information.  Also, if you put the database access in the client you have to repeat the same code and logic in each client that you write (desktop and web).

    So using a centralized service for all clients saves you time and effort, and is generally much more secure.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Marked as answer by alobi Wednesday, August 1, 2018 5:10 PM
    Wednesday, August 1, 2018 11:39 AM
    Moderator

All replies

  • Hello,

    I would suggest (if SQL-Server) looking at hosting your database in Azure and access the data via SqlClient data provider or Entity Framework for client side while it's both work web side depending on how users interact with data yo may need to look at a repository pattern were the controllers work with XML or Json for instance to feed back to the repository. BUT that is high level, more details would be needed to figure out an appropriate architecture. 


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by alobi Wednesday, August 1, 2018 6:10 AM
    Tuesday, July 31, 2018 6:49 PM
    Moderator
  • I am working on a project to automate a transport system, I am using VB.net.  Halfway through the project the client realized that some of the interaction from his clients will be done online. So this will give rise to both a desktop and web application. These two applications will be accessing the same database. I am looking for suggestion on how to do this,   have not been involve in something like this before.  If this is the wrong forum please feel free to send to the right forum. Thank you for your time

    At this point the solution becomes what is commonly known as a "distributed application".

    You will typically place the bulk of your "business logic" (the code that does all of the primary work and calculations) into some form of web service.  This web service will then expose an API that provides various methods for clients to call to execute all of the work, and will contain the only code which accesses the database.  Each client (desktop application, web application) is then little more than an input and display mechanism for calling the methods of the web service.  This allows you to safely access the database from one location and allows all client applications to reuse the same business logic.

    I would highly suggest that you start here: https://www.asp.net/web-api and examine the possible solutions.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Marked as answer by alobi Wednesday, August 1, 2018 6:09 AM
    Tuesday, July 31, 2018 8:58 PM
    Moderator
  • Thanks, this is very very helpful and a good place to start.
    Wednesday, August 1, 2018 8:06 AM
  • Thanks, this is very very helpful and a good place to start.

    You're welcome.

    The service route is generally recommended over putting data access code into each client program.  It is far more secure because the only code that knows how to access the database is running inside of the webservice, and the webservice code is not available to the end user.  If you put database access code in the client, you have to be very careful not to expose the database connection information and worry about someone decompiling your client and finding the connection information.  Also, if you put the database access in the client you have to repeat the same code and logic in each client that you write (desktop and web).

    So using a centralized service for all clients saves you time and effort, and is generally much more secure.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    • Marked as answer by alobi Wednesday, August 1, 2018 5:10 PM
    Wednesday, August 1, 2018 11:39 AM
    Moderator
  • This also is helpful, I am trying to use this for the first time and it will helpful to start the right way.
    Wednesday, August 1, 2018 5:10 PM