Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
With respect to an application that has both a web and desktop client version:
What is the best practice for the desktop client which needs access to a SQL Server?
What are the benefits of connecting to the database from the application vs using a web service?
Which one provides better security?
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Are there any other considerations that are necessary when choosing on platform?
The general rule of thumb is the following:
Write an independent data access assembly that will talk to the database.
If you are looking for interoperability between different platforms/clients then expose this assembly as a SOAP web service.
If you are looking for performance use the assembly directly in your client .NET applications.
What is the best practice for the desktop client which needs access to a SQL Server?
If you're using a local SQL Server then access the database directly. If the client has to use an SQL database on another system, the use of a web service is preferred for an additional protection and the added advantage of having a business layer that should be able to handle multiple users.
What are the benefits of connecting to the database from the application vs using a web service?
Connecting through a web service will always be a bit slower and modifications to the database will be a bit more difficult to add to the whole system. (Basically, that would mean that you need to create a newer version of the web service while maintaining the older web service for backwards compatibility.)
Which one provides better security?
The use of web services tends to be safer, although security is often more a people issue than software issue. But with the web service between the user and the database, the connection to the database is more secure since the user cannot directly access it. (Except for the functionality you provide through the web service.) This point is moot when client and database are on the same system because then the user can get full access.
What type of scope would call for one vs the other (enterprise intranet vs. web app, etc)
Web services are better for client-server applications, where users should not have direct access to the database. Otherwise, a direct database connection would just improve performance.
When creating a web service, start by writing a generic (class) library which will provide the functionality for the web service. Create a web service around this (business) library, exposing the important methods to the outside world. Any web site could call this library directly without using the web service, although you can always opt to even let the web site code access the data through the web service.
Even if you create just a desktop application with a local database, writing a business library with logic to access the database is just a very good thing to do. Your client could call this business library directly or through a web service, depending on your needs.
Are there any other considerations that are necessary when choosing on platform?
Mostly just the amount of hardware that you're willing to use to set things up. If you can afford to set up a database server, a separate web service for the services and a third for your web site, with a dozen or so client systems, then you can opt for the most layered version, where both client and web site call upon the web service, which calls the database. But if everything needs to run on a single system then just stick to the application and the business layer/library instead.
Adding layers will reduce performance from the view of a single user, though. However, working with multiple layers can improve the overall performance because resources get divided better amongst multiple users.
I'd keep it simple and minimize the amount of layers. Layers cost performance, introduce complexity, and require changes to be made in more locations.
So, if the netwerk connection between the application and Sql Server is open (typically tcp port 1433), I'd use Sql connectivity.
Given the context, there can be a big security concern with client access to databases. It requires either giving users access to the db, or creating a service account. Giving users direct access to the db poses risks. Both approaches open the door to exploiting desktop dll's to connect to db outside of application context (Multiple times I've seen cases where there is a common data access class that all functional operations use. And of course, this components initializes all the connection information. Reflection based access makes it is easy to get to protected or private methods, unless you assert Security Privileges).
Web services expose functional operations that don't expose any sql based operations. Not only is this more secure, it abstracts your client away from your data storage implementation.
Again, it depends on your context. In the Enterprise/ISV realm though, it is generally a big no-no.
If you can acces the DB from the desktop then you should do that.
You have multiple kinds of clients. That means your application should have mulitple layers.
It does not mean you need multiple tiers.
Multiple tiers can be necessary if your layers must transfer data over firewalls or if you have diverse technolgies.
I do a hybrid. Direct database access with limited user who can perform read only from the tables. Webservice with a high privileged database user who can perform write functions. The business rules are built in the webservice (audit trials, permission checks etc)
The direct db access makes it easier for me to develop reports, access lookup values from the client app.
Related
I'm new to azure and cloud platform development - I have a web application and I create multiple companies using a
company table and
seperate the
company_products using a foreign key: companyid
Is it possible to run multiple instances in which each has it's own SQL database? I want to do this because every customer is unique and they may need tailored modules.
There are no restrictions on how you build your app. You many create as many databases as you wish, and have multiple web apps if you wish (whether in the same app service plan or across multiple app service plans). How you do this is strictly up to you, but no - there is nothing that forces you to use a single database for anything.
If I am understanding your question correctly, you would like each of your customers to have their own instance and separate databases?
Have a look at this article: https://msdn.microsoft.com/en-us/library/ff966499.aspx
I'd suggest using Azure App Service, and running each of your customers in their own app. You can save money as all the apps run under the same App Service Plan. Usage on one instance however, does not affect performance on another. There are quite a lot of benefits with App Service.
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
For starting out, I'd suggest using individual Azure SQL Databases for each customer. This is to save money, as you can spin up S0/S1 databases for relatively cheap. Then you can set the connection string through the Azure Portal for each app you have under your App Service Plan.
If you end up scaling quickly, have a look at Elastic Databases. You pay for a database server and get something like 200 databases per server. So its really only economical if you have quite a few customers and can justify the cost. However there are some useful Azure tools that make managing elastic database pools easier. Check out the Azure documentation for more details on this.
Once you have this architecture set up, you can either manage your instances/databases through the portal or setup another logic app to manage all your instances. It would be a lot less development work to just manage it through the portal for starting out, however if this is a SaaS product, and is going to scale quite quickly, you may want to invest ahead of time in automating some processes so that deploying new instances doesn't have to be done manually.
I prefer this approach as well, because you can then point different subdomains at your individual custom apps. (i.e. customer1.yourdomain.com, customer2.yourdomain.com). Each app already has it's own domain under azurewebsites.net, so if you don't mind using that domain, you can just stick with it. It's nice cause then you don't have to manage your own DNS or worry about SSL Certificates and what not, as it's already managed for you. If you do want your own custom domains, there's plenty of documentation on this. Azure also has a DNS service for automating creating CNAME records while automatically spinning up a new app and deploying a DB to your pool and initializing the DB, etc...
As David says, you can do this how you like. My suggestion would be to use connection strings in your application's web.config to control the database instance you want to communicate with, and you can then configure your azure web app deployment's "slot settings" in the azure portal (or your ARM template) to override the web config settings for that deployment.
So - you can create your ARM template which describes your infrastructure, and may deploy your app service plan, web app, web config, sql database to a specifically named resource group (ie. targeting one of your customers). This would have configuration that points to the database instance in that resource group, and possibly other config that turns customer specific functionality on/off. Try to keep the code and deployment as common as you can, otherwise you'll end up with a maintenance nightmare in the future.
See https://azure.microsoft.com/en-gb/documentation/articles/web-sites-configure/ for information on configuration settings in azure web apps.
First of all, I took a look to every related topic on her about this issue. However non of them was successful in answering my question fully.
Currently I am working on a desktop app, coded in C#/wpf, that requires MySQL connection both for authentication and storing user custom lists etc.
However, the problem is that apparently allowing everyone to remotely connect to MySQL db is not good practice. Also, my current host requires IPs to be whitelisted before they can connect to the db.
What are my options on this?
Thank you in advance
You should look into creating a web service (SOAP), http web-api (REST) or some other middleware to abstract your data storage.
This has the benefits of:
Allows you to move much of the business logic out of your desktop app and into middle ware
Allows you to keep business logic out of sql which might be a bottleneck
Allows you to update your business logic without redistributing your desktop app (easier if you don't have direct control of all the desktops).
Allowing you to control authentication (many web servers have their own modules, method of authentication). Your app would control access and access storage under it's own service account.
Allows you to complete change your data storage (let's say in the future you store some in sql, some in mongodb, some in cloud storage - once again, without having to update all your desktops.
Allows you to scale out your front ends and even possibly scale out your backend storage (for example, read/write DB replicas)
If you're already working with C#, then the new MVC4 web-api should be a good fit. Read more here:
http://www.asp.net/web-api
If you go that route you could control access in your service and have your service access the database either via credentials in a connection string or if you use IIS, credentials on the application pool mapped to your site.
If you're shipping your desktop app (you're not hosting the DB) then you can also self host web-api in it's own exe if your customers don't want to install/manage IIS.
Finally, if your mysql is online, your middleware could be in the cloud (azure etc...)
Create a web service, such as with WCF or MVC Web API where your app can pass through their credentials and authenticate. I'd recommend https for transport security.
I am developing an .net Winforms application and I need to secure the connection to the sql server 2008 database. I plan to create a webservice as a middle tier that will handle the authentication and that will provide data manipulation. Is there a better way to go with? Does .net have components or tools for that? What is the best technique?
Any info would be appreciated, thanks.
Define "secure". Obviously you wish to restrict access to data to users who really need that data. However, more information about the architecture is needed; is this an in-house app that will only ever be used inside a (secured) LAN, VPN or hosted environment? Or is this an app used on computers you do not control, that will transmit data over the Internet? How much security you need depends on what types of users will be using the software, from where, and how sensitive the data is.
MSS has pretty good security built-in. You can tie SQL users to Windows domain accounts, you can restrict "securables" (tables, views, SPs, etc) in myriad ways based on user or role, etc etc. I would first look at those capabilities, and seriously consider taking advantage of them in your security plan. One SQL user defined for use by any user of a particular piece of software, which has the permissions to do anything the software may require, is simple, common, and highly insecure.
If that's not good enough, or you want to fully abstract your data layer (for instance, if you need the software to be able to be pointed at any DB type from MSS to Oracle to MySql), then it might be a good idea to implement a Repository model with a service proxy. Like Brian, I encourage you to have a look at WCF. A WCF service is highly configurable, and can provide for independent authentication and for encryption. A well-designed WCF service will be very secure indeed.
Behind the service, you can implement a Repository pattern, which abstracts the details of how data is retrieved from the data store and exposes simple methods that return objects containing the data you want in a ready-to-use form. Now, your service methods will just map 1:1 to Repository methods, possibly with some translation to DataContract-serializable objects instead of the richer domain model available on either side of the service.
Have you looked at building a service tier, using WCF? WCF can bring a whole new layer of abstraction and security from the actual physical database.
WCF also allows you to use more secure bindings than a traditional web service allows, with built-in logging.
Also, check out this book sometime if you want a really good read on .NET Security:
The .NET Developer's Guide to Windows Security by Keith Brown
I have a developed a application that is gonna to be used at multiple places.
So how should i maintain one database for all?
Or is there only one way of using remote database for this software.
If i use remote database, i am facing problem with loading controls in forms.
Please Suggest Solution.
Thanks
Typically you'd design a system leveraging multi-tiered architecture, which often consists of:
Front-end user interface
A database back-end
Middle tier/business layer that let's your web pages access the database and provides additional business logic (perhaps a web service?)
You don't give much to go on as far as details go, but it seems like you have several physical locations that need to access a single database. So you can:
Develop an (web or desktop) application that handles the front-end UI and the middle tier (which will access data and do other stuff)
Develop an application that handles only front-end UI, but calls a web service that accesses a database and does other stuff. In this case, you may have several locations with different front-end applications that consume the same centralized web service.
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.