Results 1 to 12 of 12

Thread: Desktop App with remote database

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    265

    Red face Desktop App with remote database

    Hi all,

    I need some suggestions on what technologies to use

    i will be developing a desktop application in C# with SQL back end. software needs to be accessed from different locations. I know the best answer to this would be a web application, but i don't have the resources for it.

    I found some fat client cloud hosting providers, but are really expensive. Has anyone tested running desktop apps with remote databases over TCP/IP ?

    any other suggestions

    Thanks

  2. #2
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,299

    Re: Desktop App with remote database

    Create a web service. The web service then talks to the database as local and the Windows application makes calls to the web service. Even web applications of any significant size often do the very same thing, so the web site actually talks to a web service that talks to the database rather than the web site talking to the database directly.

  3. #3
    MS SQL Powerposter szlamany's Avatar
    Join Date
    Mar 2004
    Location
    Connecticut
    Posts
    18,263

    Re: Desktop App with remote database

    The first question would be how many users and how would you best consider getting them access to the remote IP address?

    Will you have a VPN setup for the users? That is probably the most secure.

    That question needs to be answered first before you craft a web service API for consumption by the client.

    *** Read the sticky in the DB forum about how to get your question answered quickly!! ***

    Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".

    Some Informative Links:
    [ SQL Rules to Live By ] [ Reserved SQL keywords ] [ When to use INDEX HINTS! ] [ Passing Multi-item Parameters to STORED PROCEDURES ]
    [ Solution to non-domain Windows Authentication ] [ Crazy things we do to shrink log files ] [ SQL 2005 Features ] [ Loading Pictures from DB ]

    MS MVP 2006, 2007, 2008

  4. #4
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Desktop App with remote database

    I think what was proposed in post #1 was to continue to write monolithic desktop applications using some sort of Remote Desktop technology. There just isn't any path available to make such things practical, and this is why you won't find it available cheaply: supply and demand.

    Writing a "web application" was rejected for "resource" reasons. We'd have to know what "resources" is standing in for here... but I suspect we're really talking about skills and experience.

    "Web" in the generic sense buys you three things:

    • HTTP and HTTPS are firewall-friendly, partially by design but mostly by accident. Most ISPs and firewall admins cannot block these and can't even really do much to them at the proxy level without wreaking chaos.
    • HTTPS gets you fairly cheap and easy traffic encryption.
    • The explosion in use, even though mainly for trivial purposes, means the economics of demand lead to significant competition which has driven down hosting prices. If you are willing to settle for a heavily sandboxed LAMP stack things can't get much cheaper.


    As already mentioned above, "web" in the broad sense does not imply the limitations and clunkiness of a web browser front-end or the constraints of that concoction called JavaScript. You can easily front-end web services with real code doing real things at the client side.

    Of course the reality is that most applications boil down to CRUD, and once you've moved anything data-centric close to the data such applications have very little left but presentation to implement on the client. Once your client is that thin it may as well be script and markup in a browser. The death of SilverLight meant the death of C# in the browser. If you want cheap you're looking at LAMP, so both C# and SQL Server are off the table there too.


    Changing any of this changes the economics. You can find ASP.Net/SQL Server hosting, but it will never be as cheap as LAMP or even WAMP. The next step up in cost is probably Node.js hosting even on Azure these days. If you change the client from browser script and markup to anything else the cost increases because browser scripting is the cheapest skill on the planet today.

    As I already said, unless you can do enough work at the client side to make performance and flexibility matter... even if you have C# programmers working for free it doesn't buy you much. But if the client development cost doesn't matter then sure, go ahead and build a C# client.

    Using sophisticated client logic only makes sense when the common datastore is relatively low-usage. That can still be a ton of application domains. For example nobody in his right mind writes browser apps for mobile: by their nature they consume too much scarce, slow, and expensive bandwidth. These do as much as they can on the client, relying on hosted services merely for things like notifications, low-volume data access to resources impractical to hold on the device, and posting results and state data.

    But nobody really considers mobile devices to be CRUD data entry platforms anyway.

  5. #5

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    265

    Question Re: Desktop App with remote database

    Quote Originally Posted by szlamany View Post
    uld be how many users and how would you best consider getting them access to the remote IP address?

    Will you have a VPN setup for the users?
    At this stage it is 5 to 10 users but may increase in the future. Won't be using a VPN, i have been doinf some research and most likely to go with Azure database. my only concern is

    it requires client IP to be whitelisted in the firewall settings, what means the list needs to be updated whenver the client IP changes

  6. #6

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2009
    Location
    sydney
    Posts
    265

    Re: Desktop App with remote database

    By resources i meant expertise, time and budget. I like @jmcilhinney idea of having a service to communicate data between client app and database

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Desktop App with remote database

    I'm not sure what Azure really brings to the table. You can probably find a cheaper option for database hosting even if you insist on using SQL Server.

    But any scheme that is going to support monolithic coding will run into the issues of performance, reliability, and of security and visibility (your "whitelisting" of IP addresses for firewall penetration).

    This is where web services came from: the idea was to replace robust high-performance protocols such as DCOM to interconnect n-tier applications with the good-enough, firewall-friendly, and more Internet-safe HTTP protocol. But before you can use HTTP you have to move away from monolithic design by moving as much data access and business logic as possible as close to the DBMS as possible.

    That doesn't mean you clients can't still do a lot of crunching, but that's usually a special case. If you have a central DBMS than most likely your application is... data centric. The more you need to work against that central database the thinner your client tends to get.

  8. #8
    MS SQL Powerposter szlamany's Avatar
    Join Date
    Mar 2004
    Location
    Connecticut
    Posts
    18,263

    Re: Desktop App with remote database

    All my web services run over SSL/HTTPS - security still has to be considered if the data is in any way sensitive.

    *** Read the sticky in the DB forum about how to get your question answered quickly!! ***

    Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".

    Some Informative Links:
    [ SQL Rules to Live By ] [ Reserved SQL keywords ] [ When to use INDEX HINTS! ] [ Passing Multi-item Parameters to STORED PROCEDURES ]
    [ Solution to non-domain Windows Authentication ] [ Crazy things we do to shrink log files ] [ SQL 2005 Features ] [ Loading Pictures from DB ]

    MS MVP 2006, 2007, 2008

  9. #9
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,532

    Re: Desktop App with remote database

    Quote Originally Posted by dilettante View Post
    I'm not sure what Azure really brings to the table. You can probably find a cheaper option for database hosting even if you insist on using SQL Server.
    Depends on what you're looking for... Azure gives you the ability to upscale and downscale on demand... with replication to multiple datacenters, allowing clients to be able to connect to the nearest center for performance... Google offers this kind of support as does Amazon Data Services ... not many others do... We currently support the use of the Amazon services for our product... a few are using Azure, but mostly for testing, and because our MSDN subscription gives use free azure services on a limited basis. But if in the future we think we can get more bang for the buck from Azure than we can from Amazon... eh, we'll move things over, tweak a couple of configuration items and our clients wouldn't notice the difference (except maybe for a short planned maintenance "outage.")

    It's that ease of scalability where ADS and Azure (and the google offering, the name of which escapes me) really shine...

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  10. #10
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Desktop App with remote database

    The security achieved by simply using HTTPS vs. HTTP is wildly overstated unless you are issuing and using client certificates. Since it costs you little but performance though, blind usage is probably a no-brainer in most cases. At least you can pretend you are "secure."

    Cloud database hosting doesn't offer scalibility "for free" though, and requires a bit of effort to achieve, see:

    Elastic Database features overview

    You can usually get usage-based pricing with little effort.

    Moving workload into the cloud front-ended by a web service (or the degenerate case of dumb client, i.e. browser-based application) is a well-known, simple request/response scenario that is far easier to provide simple scaling for. But this isn't "zero effort" either since you have to cope with multiple instances that won't always be synchronized.

    Most usage of Azure is single-instance just to avoid dealing with the complexity. At that point scaling has been tossed out the window.

  11. #11
    MS SQL Powerposter szlamany's Avatar
    Join Date
    Mar 2004
    Location
    Connecticut
    Posts
    18,263

    Re: Desktop App with remote database

    Quote Originally Posted by dilettante View Post
    The security achieved by simply using HTTPS vs. HTTP is wildly overstated unless you are issuing and using client certificates. Since it costs you little but performance though, blind usage is probably a no-brainer in most cases. At least you can pretend you are "secure."
    blind usage - no brainer - pretend... Word choices matter - you sound like you are smacking us over the head with this information.

    Web service security is important. I issue a GUID upon initial successful credential validation and then use that GUID in every subsequent web service call. It's validated against a pool of known current logged in GUID's and if not found or timed out we refuse the service.

    All of this done HTTPS so no data in clear text to be reviewed by bad guys.

    It passed a HIPAA level security review by an outside firm that one of my clients hired - I feel good about what I've done for security.

    No brainless, blind or pretend stuff going on here...

    *** Read the sticky in the DB forum about how to get your question answered quickly!! ***

    Please remember to rate posts! Rate any post you find helpful - even in old threads! Use the link to the left - "Rate this Post".

    Some Informative Links:
    [ SQL Rules to Live By ] [ Reserved SQL keywords ] [ When to use INDEX HINTS! ] [ Passing Multi-item Parameters to STORED PROCEDURES ]
    [ Solution to non-domain Windows Authentication ] [ Crazy things we do to shrink log files ] [ SQL 2005 Features ] [ Loading Pictures from DB ]

    MS MVP 2006, 2007, 2008

  12. #12
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Desktop App with remote database

    The point is that unless you really think you are a "hot" enough or critical enough target like a bank or a major service provider the odds anyone is going to try to tap into the Internet backbone or even sniff your WiFi traffic are very, very small. So HTTPS doesn't really buy you much.

    If you have a regulatory requirement to use HTTPS it is another matter and sure, you'd use HTTPS as a matter of course. It still rarely matters in reality, but why take a chance? Thus a "no brainer."

    I saw nothing in the OP's requirements to suggest the overhead is warranted though, and choosing HTTPS doesn't help solve his problem at all. After he has his problem solved he can always adopt the extra resource consumption of HTTPS trivially later on.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width