Jerry Dodge
Jerry Dodge

Reputation: 27276

SQL Server Layer for both Delphi and C#

I really don't like the concept of opening my SQL server(s) to the internet - even if I can lock down the firewall. However I've always been working directly with databases. I'm building a system now which involves 1 SQL Server database, a web application in ASP.NET/C#, and a few windows applications in Delphi XE2. But from the beginning, I'd like to put some sort of 'filter' around the database so I don't have to open it up.

I know there are many things out there for this, but don't know anything about them or what to get for my scenario. I'd like to keep it native to SQL Server; I don't plan on using any other type of database engine.

It needs to be connected from client to server by other means than the standard SQL connection, like a filter. It creates its own encrypted packets and transfers data its own way. I will have a wrapper class for both Delphi and C# which will pretty much be identical - and be able to stream its data into the DLL to interact with the DB.

Now there are three different ways I can go about this...

I would much prefer the second option, and do not want to go anywhere close to the first one, and can't do the third one at all.

So any good libraries for database layers? And might there be some already installed in Delphi XE2? I'm thinking maybe an encrypted XML packet?

As an example, let's say I have a table for 'Customers'. In both my website and applications, I should never have any SQL script like select * from Customers or no SQL script in general. Instead, I will have a wrapper around the database. So I can call a function such as DBGetCustomers(Conditions: TGetCustomersConditions): TDBCustomers; where TGetCustomersConditions is some way of filtering the query, and TDBCustomers represents the results from the query.

There could also be a function DBAddCustomer(Item: TCustomerToAdd): TInsertSuccess; where TCustomerToAdd represents what to insert, and TInsertSuccess represents any result, such as error message(s) or rows affected. I do not intend for it to be working exactly like this, but just to explain the concept of any wrapper in general. When the app sends to request to the server, it still has not converted anything to a SQL Query. By the time the request gets to the server (which is able to connect to the database), then the server alone decodes everything to the SQL query.

Upvotes: 0

Views: 686

Answers (4)

whosrdaddy
whosrdaddy

Reputation: 11860

Kbmw allows you to make a ntier db architecture.

However since you have a web application involved, a better option would be WCF (as already suggested)

Upvotes: 1

Mad Hatter
Mad Hatter

Reputation: 772

What's the problem even if you have just one "hosting spot"? A web service is just a "site". And a web server can easily host multiple site even with a single IP address. Anyway, what you're looking for is an "application server" in a multi-tier design.

While Java invested heavily in that direction, MS did not. Delphi has Datasnap, which is a so-so framework, don't know if the new "restful" interface is easily callable from C#, it looks to have security flaws though. The .NET way of doing it is using WCF, as long as it uses a standard protocol you can call if from Delphi has well.

You could also look at RemObjects DataAbstract. It's not open source, but it is a mature library.

Upvotes: 3

mjn
mjn

Reputation: 36644

If you already use a ASP.NET C# web application, you could also add a WCF (Windows Communication Foundation) based web service to your web site. This can provide database access to external applications, which need to connect the web service somehow. It should even be possible to use the same HTTP standard port for both the normal web site pages and the service, by mapping the web service to a specific context path like www.example.com/services/servicename

Upvotes: 1

Peter
Peter

Reputation: 1045

One of the 'traditional' ways to do this is via webservices (although this technique is now considered by some to be a bit dated).

One disadvantage is that it is not a generic wrapper you can throw around the database, but it has the advantage that you can limit access to the database easily to specific stored procedures for example, which will maximise security, and is a standard technique if you wish to provide limited authorised access to external applications.

Upvotes: 1

Related Questions