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.
Related
When it comes to mobile applications a lot of the time the client is going to be offline.
Right now when the user submits data on the client it is saved locally and then when they press the sync button everything is pushed and pulled between the client and the server.
What would be the best practices when it comes to synchronization of data?
Server side I have a very large MS SQL Server and client side I have sqlite at my hands.
You might find this (This is Microsoft Application Architecture Guide v2.0, Oct 2009) useful. I am facing the same problem here at work, and I did find these guidelines useful early in the process of thinking.
To share my experience, I think the major decision comes from the problem you are trying to solve. If You're facing a single, fixed, mature business domain (i.e, rarely changing your db schema and you face just one or two clients) you can build your own data synchronization framework. This is far better than using commercial or non-commercial frameworks in terms of ease-of-use and adjustment + performance. + Store-and-forward is a very good feature that can overcome your connectivity issues.
However, If you are facing a changing (not necessarily expanding) business domain, or maybe different clients with different requirements you might want to use a mature framework (like Microsoft Synch Framework) to do some parts of the work for you and you can focus on the adjustments needed to your requirements.
I hope this isn't too general.
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
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.
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.
I want to install a desktop application (on many stations - about 10-20) should access the SQL Server directly, no Services, and no server-DALs.
The application will be installed on a local network on about 10 machines, while one of them is a server.
When I will install the program I will set the connection string, and the applications will talk directly to the SQL server.
Is this a bad idea?
If yes, then how bad?
It is not necessarily a bad idea. If you won't need to scale then it's a valid approach.
What you are describing is often called a 2-tier client-server architecture.
You should probably encrypt the connection string in the config file (but this will only stop prying eyes, not someone intent on recovering your password). The other option is to use Windows authentication via a trusted connection, but you do lose the ability to connection pool, but that should not be an issue with 10 - 50 clients (ballpark).
Of course not.
What your describing is classic Client Server architecture, and around 50% of apps are still
built this way, according to a survey I saw recently.
Bob.
I have built plenty apps like that. I would suggest you build a DAL that is in the app itself so that if you ever need to separate data access and presentation layers, you can do so easily (plus there are other benefits like standardization of code, single place to change things, etc).
I don't see an issue with it as long as you are consistent and follow best practices.
If it's on your local network, go for it.
If it's over the internet, I'd create a web service.
Also note that there are plenty of off-the-shelf DALs (NHibernate, Entity Framework) so you don't need to roll your own, and the work just as well in client server architectures.