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
Related
I'm using a desktop application that writes its data to SQL server. I don't have the source code of this application nor is there an API I could interact with but I do have access to the database.
Besides this desktop application, I'm working with other web based applications that offer a REST API for interaction.
Now, my goal is to act on specific changes I make in the desktop software and push these changes automatically to the web service. For example, if I create a new customer in my application, I want to have the same customer created in the web service.
The easiest way of doing this IMO is to just introduce a trigger in the SQL database and consume the API of the web service directly from T-SQL.
Researching this topic, I came across many comments saying using SQL Server for this is not recommended, too expensive etc. I fully understand where they are coming from, even though in my own case cost or performance really won't matter that much.
Still, I'm wondering, what would be the correct (or at least better) way of doing what I'm trying to do without considerably blowing up complexity?
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 have built an extensive 2-tier application in D2010, using ADO and devexpress. I want to upgrade this to using Datasnap mainly to provide HTTPS communication instead of just TCP/IP to the vulnerable SQL server. I have followed all the Datasnap tutorials I could find. I have Cary Jensen's Delphi In Depth: ClientDatasets. All good and well, but the examples are pretty useless because in a REAL database application, grids are populated from joining multiple tables together and almost never from a single table. This obviates the "autoresolve" capability of clientdatasets right off the bat. Even the proposed beforeupdateevent handlers won't work in a datasnap application because the DB is only accessible to the datasnap server. So it seems to me I have to create a method on the datasnap server for EACH insert/update I am going to need, then expose those methods to the client and call them from the client as required to request the datasnap server to perform the required update/inserts. This seems like a lot of work!
Is there an easier way to implement https comms to a SQL Server?
Oh in case you're wondering, the application is already pseudo 3-tier in that grids are wired to TdxMemData, and never directly to TADOQueries. I handle all insert/updates myself in the same way that I would have needed to if I had used TClientdatasets.
If you think your database is vulnerable think twice about using D2010 Datasnap. It is very, very vulnerable. Don't be fooled by HTTPS, there are still lot of pieces missing to fully protect the channel. For example once you use Datasnap, SQL server Windows integrated authentication (kerberos based...), is gone.
For a full explanation see: Why Datasnap 2010 is a toy library. It's of course my personal opinion, but is is based on my experience using Midas/Datasnap since Delphi 3, and my current work about IT security.
Anyway you're wrong about insert/updates/deletes. You have to use providers' events to control them on the datasnao server side. It's a bit more complex than handling them in a two-tier application, but you don't need ad-hoc methods for each operation.
[2016 Update: DataSnap in 2016 is even more woefully behind in terms of security and features now than it was when this question was written. I do not recommend its use in any new designs at all, ever.]
DataSnap is a solution to the problem of building multi-tier (Three or more) applications. Directly connecting to SQL over the internet from a thick client that contains all the business logic in the client has many well-understood problems, including the fact that business logic changes then require that you update ALL your clients at once. A middle tier improvement (business logic change) that is inside your data-snap (or other) middle tier logic, is not distributed to each client. The clients are thinner, and contain less of the business logic. Secondly, a well designed data-snap "API" that you build yourself only exposes you to the risks that you create yourself, rather than exposing you to the entire set of MS SQL vulnerabilities.
Frankly, losing Kerberos authentication from your thick client, is not a reason to abandon the idea of a middle tier. I don't understand ldsandon's point at all here. Is he advocating a two-tier application architecture that connects to internet or LAN clients, and that contains all the business logic, as "more secure" than a multi-tier application?
The implicit question suggested by your title is unanswerable, and undefined. What does "real" mean? Many industries deploy two-tier thick clients inside their own corporate LANs. Many have found it beneficial to use a middle tier inside their own LAN, and many have found that external applications that run over the internet should definitely NOT be surfacing the SQL connectivity to thick clients, and so they provide some kind of "web method" (SOAP, REST+JSON, etc) architecture. It has been carefully pointed out that Data-Snap is not a Purely "RESTful" architecture, but it does use JSON, and is in many ways REST-ful in design, although not fully.
If you don't understand the problem that DataSnap was created to solve, it is easy to think DataSnap is worthless, or (alternatively, and equally wrong) some kind of silver bullet. It exists for a particular purpose, one that many people find useful for their development needs. If you intend to take on the work of making a middle tier, DataSnap makes it easier than to do it 100% as a "roll your own middle tier", but it is more work than not having a middle tier.
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.
Is it possible to access the database backend of a sharepoint server? My company uses Sharepoint to store data and pictures of various assets. Ideally I would be able to access the data and display it in my application to allow users both methods of access.
Before I go talk to the IT department I would like to find out if this is even possible?
Edit: From rails on linux? (Yes, I know I'm crazy)
Agree with Adam. Querying the Sharepoint Database is a big no-no, as Microsoft does not guarantee that the Schema is in any way stable. Only access the database if there is really no other way.
As for Sharepoint, usually the Lists.asmx Web Service is what you want to look at first.
http://www.c-sharpcorner.com/UploadFile/mahesh/WSSInNet01302007093018AM/WSSInNet.aspx
http://geekswithblogs.net/mcassell/archive/2007/08/22/Accessing-Sharepoint-Data-through-Web-Services.aspx
yikes! :)
look at the web service and .net API before going direct to the database. i've used both and they provide plenty of flexibility (including building your own web services on top of the API if necessary). API for on server clients, web services for off server clients.
Just a small comment. Never ever go to the database direct. If there is no way to do it via published and supported API's, then there is no way to do it. End of story. This applies even to when you are "just reading data", as this can still cause significant issues.
Just to support the above if you ever take a look at the SQL tables that sit behind SharePoint you'll realise why its not recommnded or supported to access the database direct. MADNESS!