VS2010: What is the best way to access a remote database over the internet from a WinForms application? By that I don't mean talking to the database (SQL Server) directly, but rather through a service. Best if I could use http as a protocol to avoid firewall issues.
Would recommend that you look at WCF
If you have control over both ends of the connection, you then can change protocol etc through configuration, but yes, http:80 is usually the easiest way to adhere to firewall policies.
If you wish to keep this simple and your needs are limited you could always use a typed dataset that you pass over WCF (or .Net Remoting). However you will quickly hit problems if your app gets more complex or you have lots of data.
SqlServer will exposed stored procs over soap, this may work well if your applications uses a few stored procs that are not too chatty.
Exposing your data with WCF Data Services is an option if you want simple CRAD operations.
Otherwise you will have to define all the methods you need on WCF interfaces.
If you are not tied to WinForm, look at WCF RIA Services with Silverlight as this will do a lot of the hard work for you with most CRAD type applications. But you will need to learn Silverlight.
The problem is there is no simple and
easy solution to “presenting the
internet is not in the way” and moving
to a 3 tier application will always
make your code more complex. A 3 tier
architecture can be great for more
complex and demanding applications,
but is often over kill.
Also consider writing a 2 tier WinForms application and using Terminal Services to expose it to your clients over the internet. This is often the cheapest solution and tends to give the least pain with system admin. However a lot of programmers think it is “cheating” for some reason.
Related
I am building a desktop application that will be used on local network, with SQL Server as database.
This application would have around 50 users top at the same time. In what particular scenario would I need to use WCF service? Is it recommended to create a WCF service on the server computer where database would reside, so we connect to this server through WCF service, instead of connecting to the database directly? What is the recommended way to connect to SQL Server data and why?
Edit: Let me explain in more detail. I have used WCF Ria services before, so I know how they work. Lets assume that WCF services works in same way. The question was directed toward why would we use WCF instead of directly connecting to database? I didnt want to specify my current application requirement, since I would get a specific answer for specific requirement. My goal was to understand in general why and when would you yse one instead of another. And I have received satisfying answers so far.
It appears to me that general consensus is to use WCF only if there would be a demand of another type of application, which would use web access to get data from service. Also, if I understood correctly, from security point of view, there is no difference between the two.
There would be a statistical app in the future that uses web to provide read-only statistics to user, and naturally some service will be required for this task (application has no specific client in mind, it will be offered to lots of clients). Since I need some demo application to be done very rapidly for particular clients, then I am thinking to neglect the service part, and make a proper layering (WPF->VM->Model->EF, so later I would just insert service between the model and EF. I guess it should not take too much time to make WPF app running with inserted layer. I am also postponing the service because of next reason: since HTML5 is (going to be) main technology for web, and there is a possibility that SL will be abandoned as technology (which I have been using), the logical decision would be to choose HTML5 over SL. But since I am totally unfamiliar with HTML5 and its requirements, I am not sure if WCF service is the best choice for it, and this is also one of the reasons to postpone the decision of choosing the service type (along with requirement to make the desktop demo app as fast as possible).
I think a better way to consider the question is whether you should abstract your database and data access layer from the application using a service interface. You could use WCF and SOAP or you could use a REST based HTTP service, the choice of technology is secondary to whether the current or future requirements of your application indicate that an additional layer of abstraction is warrented.
Reasons you might consider using a service interface instead of directly connecting to the SQL database include but are not limited to:
Ease of supporting multiple operating systems/client UIs
Ability to evolve the data/service interface separately from your database schema
Isolate application from changes to database schema or location (you don't have to redeploy change to application, only change internals of the services it is calling)
If data could be used by other systems, you have a standard means of allowing these systems to interface with the data your application is managing
Reduced SQL database connection security concerns (only service identity connects to database, allowing you to use a variety of authentication/authorization strategies on the client side)
The trade off you are looking at is the time/cost/complexity of implementing a service interface versus the flexibility and mantainability benefits you will gain. You should evaluate the needs of your application and your customer before you make a decision on whether to connect directly to your data store using ADO.NET or use a service layer.
You should take a look at the Microsoft Service Layer Guidelines as they cover a lot of the considerations to take into account.
Unless you need to create a reusable service, I can't think of a reason to add a WCF layer, unless you are just looking for a reason to do it. I think you can just go with some sort of ORM like EF or nHibernate and be happy.
The main reason for WCF is security. If the client connects directly to the DB then the client must be given rights on tables. The client can hack into the connection and use TSQL directly. You must expose port 1433 to the network in a single tier application. With WCF there is not direct access from the client to SQL. It is not just more secure in general but you can have more granular security. .NET service code can enforce row level security. A table only has column level security. If this is business on a private network and you don't expect anyone would try and hack into your db then client connecting directly to the SQL server is easier to build. With server side service the other factor is a change to server side code is one spot so you don't have to update 50 devices.
I am thinking about replacing the business layer with BizTalk orchestrations exposed as WCF services as a standard architecture for many of our apps. Essentially ASP.NET and WinForms apps will call these services to retrieve and update data in many of our LOB databases among other things. Some of the services will also be exposed to partners.
As for the data access, I can certainly use the SQL Adapter, but I think it's not the cleanest way to do it, and the fact that it's tightly coupled to SQL Server also makes it a bad idea for me. I would like to use Entity Framework based custom DAL's or perhaps generated from tools like SubSonic, etc.
Is this a good idea? From my Google searches, I can't find many people doing this kind of thing or any comments on how it might have worked out for them.
What's your take on this? Any ideas on where to cache data, concurrency issues, etc.?
You will probably have an easier time using straight WCF and something like NHibernate or EF. These services consuming and returning DTO's and not raw entities. If you do have heavy business logic or mapping that needs done, BizTalk can sit in front or with ESB even expose mapping services to your data service on the side.
Also check out the new WebApi stuff. http://wcf.codeplex.com/
And BizTalk is not great at doing low latency ... you will get some overhead on all the service calls.
If you have to do a lot of service aggregation there MIGHT be a case for doing it this way ... but beware the latency and overhead you get from an integration platform that is aimed at giving you all kind of services around messaging integrity etc.
I am using MonoDevelop and MonoTouch to create an application which needs to access SQL Server 2008 tables. I understand that if you use objective-C then the only way to access SQL Server is via web service but what about MonoTouch. Is there anything better than coding a web service when using MonoTouch?
Better? I would say no there isn't. Creating a Web Service is the way to go in this scenario. You keep your data access layer on the server, you keep your security footprint small, and you enforce data validation on the server-side. All of this keeps your MonoTouch application smaller and focused on the Presentation layer and Business Logic Layer.
From your question, I am assuming you would rather stay away from WCF but it really is the way to go. This way you set yourself up to work with MonoDroid, a website, Windows Phone 7, or other platforms without additional Data Access (and possibly Business Logic) layers needing to be written. Even if my research didn't suggest that there isn't a SQL Server connector for MonoTouch, I would still recommend going with WCF. From what I have seen though, it doesn't seem like you have a choice here.
I recently attended the Microsoft Mix event and sat through these OData presentations. It includes code samples for obtaining data via objective C or any other subscriber/device/language from an OData provider (including SQL Server). They are well worth the watch if you're interested in data access technologies.
http://channel9.msdn.com/Events/MIX/MIX11/FRM10
http://channel9.msdn.com/Events/MIX/MIX11/FRM11
http://channel9.msdn.com/Events/MIX/MIX11/FRM16
Please I need help.
I have project in which I need application which communicates with local DB server and simultaneously with central remote DB server to complete some task(read stock quotas from local server create order and then write order to central orders DB,...).
So, I don`t know which architecture and technology do this.
Web application, .NET WinForms client applications on each computer, or web services based central application with client applications?
What are general differences between this approaches?
Thanks
If you don't want to expose your database directly to the clients, I'd recommend having a web service layer in between. Depending on the sensitivity of your data and the security level of your network, I'd recommend either a web service approach (where you can manage the encryption of data yourself, and without need for expensive ssl certificates) or a web interface (which might be easier to construct, but with limitations in security).
I agree with Tomas that a web service layer might be good. However, when it comes to choosing between webforms or winforms I don't think your question includes enough information to make the choice.
I'd say that if you want a powerful and feature rich user interface and want to make development easy, Winforms is probably the way to go. But if you need it to be usuable from a varied array of clients and want easier maintenance and deployment, a web app might be best.
First, focus on the exact relationship between these databases. What does "local" mean. Right there on the user's desktop? Shared between all the users in their office? Presumably the local quotes (you do mean stock quotes and not quotas?) could potentiually be a little out of date relative to the central order server's view of the world. Does that matter? I place an order for 100 X at price 78.34, real price may be different. What is the intended behaviour.
My guess is that there is at least some business logic and so we need to decide where that runs. One (thick client) approach is to put that logic on the desktop, the desktop app then might write directly to the central DB. I don't tend to do this for several reasons:
Every client desktop gets a database connection. Scaling is not good, eventually the database gets unhappy when the number of users gets very large.
If we need a slightly different app, perhaps exposed to a different set of users via the Web or whatever, we end up reproducing that business logic.
An alternative approach (thin or browser based) keeps the UI on the desktop, but puts the logic on the server. The client can then invoke some kind of service. Now there's lots of possible ways of doing that, a simple Web Service or Rest Service will do the job. I hope it's clear that this service-based appraoch addressed my two points above.
By symmetry I would treat the local databases in the same way, wrap them in services. However it's possible that some more complex relationship between the databases exists and in which case you might need the local service layer to interact with the central service layer.
I'm touting the general pronciple of Do Not Repeat Yourself, implement each piece of business logic once.
There are some rumors floating around that the team at my company will soon be using web services for all future application development. The architecture is supposed to be something like this:
Application --> Web Service --> Database
The stated reasoning behind it is security. This sounds like a huge waste of time for little if any benefit. My question is, in what ways does a web service make your data more secure than a database? I would think that if an attacker wanted to get all your data and had already gotten onto the app server, it would be fairly trivial to figure out how the application is getting it's data.
Please keep in mind that these web services would be purely for data, and would have little if any business/validation logic, and would also be outside the application developers control (at least that's the way it's worked with all previous applications that have used web services).
If it's true that there will be no business logic or validation on the web services, then there is only a limited security benefit to adding the additional layer of abstraction. I say limited because the interface between your application and the database is still more limited than if they were directly talking to each other.
If you add validation and business logic to the equation, there is a significant security benefit, as anyone who has access to the application account can only do the database what the application is able to do. Additionally, this is a better design because it reduces coupling between your application and implementation details of how the data is stored in the database. If you wanted to change the database schema, you only need to update the web services, and not entire applications.
One important thing about Web Services is interoperability so that different applications from different platforms later can utilize the services and data. Your company will benefit a lot by doing so. And you are right about the security, it is definitely one of the good reasons to use web service rather than expose a public endpoint of the database, it is dangerous!
Web Services enable the accessibility of your data, For example, your data can be accessed within browser by javascript. There is no way to access the database on the server directly within Javascript.
All in all, go for it, that is the right approach.
the security argument is questionable; authenticating to a web service is no different than authenticating to the database
there are legitimate reasons for moving db operations to web services and SOA in general, but security isn't one of them
If you use a webservice hopefully you will also be using some kind of queue when sending the data to the database. If you are using a webservice and queue combo then the security come into place with less chance of lost data. If you do not have a webservice and queue combo if you send data to the database and it never gets there you have no were for it to go it just disappears.
You are correct though if someone wants to break into your system a webservice isnt going to help if anything it might make it worse if you make the webservice public and they find the name of your webservice because then they can just query your DB using the webservice and any security features on your servers will just think it is you applications getting the information.