views:

69

answers:

3

Hi,

If I wanted to have my data in SQL Server, but wanted to use a thick client WinForms application for users, what would be the best practice way to have calls occurring from WinForms to database? And how simple is this?

I guess I'm trying to gauge to what extent there are issues with this approach and one needs to go for some (a) middle tier with web services, or (b) have to go asp.net or something.

I really just have a simple app that needs a database and I'll only have a 10 - 30 clients on a LAN/WAN network that would be connecting in.

EDIT: So the focus of my question was regarding the communications protocol/approach from the client PC to the Database, i.e. over the LAN/WAN

+2  A: 

A simple way is to use an ORM such as LINQ to SQL. This will save you having to write the SQL yourself but still generate reasonably efficient database queries. Other examples of ORMs are the entity framework and NHibernate.

If you want to write the database queries yourself then you can use ADO.NET.

You might not want clients to have direct access to the database but instead to communicate to a service you are running. Then you could choose to create a WCF service instead of allowing direct access to the database.

Mark Byers
Mark - thanks. So the focus of my question was regarding the communications protocol/approach from the client PC to the Database, i.e. over the LAN/WAN. Are you suggesting WCF would be the best answer? (i.e. avoid direct database traffic?)
Greg
@Greg: It's unclear whether you want the simplest solution or the best practice. The simplest short term solution would be to allow direct access to the database. But this will become problematic in the long term because if you modify your database structure too much you will have to redeploy all your clients. I'd recommend WCF so that your clients aren't directly dependent on your database structure.
Mark Byers
I guess I meant simplest best practice if this makes sense Mark. I've never used WCF before, it is a large ramp up to get across this?
Greg
@Greg: It requires a little understanding to get going, but not a lot. Tutorials are available: http://msdn.microsoft.com/en-us/library/ms734712.aspx
Mark Byers
A: 

Having a data access layer would be a good idea as it will separate your choice of data persistance from the rest of your application and allow you to more easily change it should the need arise in the future.

If your data is heavily object related then you might decide to use an Object Relational Mapping tool/framework to map the application entities to the data in the database. If you don't want to use an ORM, then the least you should be doing is using parameterized SQL statements.

Russ Cam
thanks - so the focus of my question was regarding the communications protocol/approach from the client PC to the Database. I've updated the question to clarify this, sorry if it wasn't clear.
Greg
+2  A: 

The simplest solution if you have PC's and DB server close by is to use direct Linq-to-SQL approaches - no extra WCF service layer in between. Such a service layer adds a significant amount of complexity.

If you want to go that route (maybe because of your WAN clients), then I'd recommend you check out the WCF Data Services, a layer on top of bare WCF. It's probably the easiest and quickest way right now to expose a data model (e.g. your Linq-to-SQL or Entity Framework model) as a REST feed to WAN/internet clients.

WCF in itself is indeed a big beast and thus scares away a lot of folks - but you don't need to know each and every setting and knob it has in order to use it. For some intro to WCF, I recommend those two episodes of DotnetRocks TV - excellent intro material:

marc_s