.NET Database application guidance.

views:

101

answers:

.NET Database application guidance.

Hello, I'm stumbling in the data wilderness and feel very lost, so i am asking for help. I have done some database apps in VS (C#) winforms for some time, wpf lately. These are small to medium apps (embedded dbs, a bit of sql server), like a restaurants, cash registers and similar. (15-20 tables)

Until now, i have done all my datasets by drag and drop in Visual Studio designer. I spent weeks on web trying to find some complete solution how to write complete solution with typed datasets by hand from scratch (DAL, B.Objects) in hope to learn some architecture patterns along the way, but without success.

So, finally question. Can someone recommend me what to learn for this type of applications, maybe move away from datasets , use some ORM ( maybe overkill, i dont know). Point me in some direction please.

+2 A:

Have a look at Entity Framework

EDIT Link is updated to EF 4.0

Incognito 2010-05-22 22:23:31

For someone new to ORM EF may not be the best approach. It's got a lot of powerful features, but a bit of a steep learning curve.

R0MANARMY 2010-05-22 22:27:36

Yeah I know about EF, i heard it had some problems before, dont know now. Anyway so general is it a good idea to dump datasets although i'm not expert in them, and going to something newer and much advanced like EF?

Wally 2010-05-22 22:29:13

I would say that to do a basic app with EF(i.e. The equivalent of what you would do with linq to sql), the learning curve isn't that steep, however, to use more advanced features, the learning curve does get steeper. However, by starting with the entity framework it may be easier to modify apps to use the more advanced features it offers later on.

grrrrrrrrrrrrr 2010-05-22 22:33:22

Yes if you want something lightweight you can use linq2sql, but bear in mind that MS will support EF more intensively.

Incognito 2010-05-22 22:41:24

@Wally: The problem you're probably referring to is the vote of no confidence (http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/) it got a few years back. The ADO team has since done quite a bit of work to improve the platform. For me the most annoying part of using EF was the designer. Although it's great for when you are just starting out, once you get more comfortable with the concepts it can get quite tiresome to have to click around all the time to add fields. Also the diagram can get a bit unmanageable when you have lots (dozens) of entities.

R0MANARMY 2010-05-22 22:44:48

+2 A:

Using typed datasets is pretty close to using stone tools. They served a purpose once but better technology has since been developed.

If you wanted to go NHibernate route, there are a couple of excellent articles on nhforge

Two new NHibernate Quickstart Tutorials
Part 7 (that links to the other 6 parts) on building a WPF based NHibernate applicatoin

NHibernate may be overkill for your needs if you were using typed datasets before. However, Linq-to-SQL could be a good fit. ScottGu has a nice 9 part series on using it with ASP.NET (but a lot of it will apply to WPF as well).

I think officially Microsoft won't be developing Linq to SQL any more in favor of Entity Framework, but for the time being it's still a fairly lightweight and useful framework for getting started with ORM.

R0MANARMY 2010-05-22 22:24:36

NHibernate sounds good also, heard of it is like some kind of industry standard orm. Especially if i need to make transition to java later. ( I'm still student ).

Wally 2010-05-22 22:31:58

+1 for NHibernate

Jeff Schumacher 2010-05-22 22:36:40

@Wally: it's probably the most mature ORM for .NET out there, I wouldn't necessarily call it an industry standard. I don't know how helpful it would be with making a jump to Java. Although Hibernate and NHibernate share a lot of the same features, there are quite a few differences. For example you're more likely to use something like FluentNhibernate to define your mappings in NHibernate vs JPA annotations for Hibernate. NHibernate 3 is also getting a proper Linq provider (which Java won't support).

R0MANARMY 2010-05-22 22:38:38

Well, i guess linq to sql is off because i would like to have ability to ship app with optional embeddable db or full fledged db.

Wally 2010-05-22 22:52:06

I'm curious as to why DataSet is considered "stone tools." I've been using it for a while, and it's simple and does the job. What does this new ORM stuff do?

Carlos 2010-05-22 23:12:53

@Wally: Depends on which embeddable db you go with. Linq2SQL plays nice (sorta) with SQL Server Compact edition (which I believe can run in-process).

R0MANARMY 2010-05-23 03:09:57

@Carlos: It depends on the use case really. The links I added as a comment to the question would be a good start. The most obvious example I can think of where DataSets fall short is relationships. In any even mildly complex app you aren't just dealing with simple objects, you're dealing with object graphs (objects with collections and many-to-many style relationships with other objects). Mapping and retrieving those using an ORM can be quite a bit easier than pulling it into datasets and trying to create those relationships manually.

R0MANARMY 2010-05-23 03:16:21

For small-medium, Entity Framework is a good option in my opinion. There is a Beginners Guide (http://msdn.microsoft.com/en-us/data/ee712907.aspx) on MSDN that I found usefull while exploring this. Also be sure to read up on Data Access Practices Using Microsoft .Net: A Nerdly Comparison (http://msdn.microsoft.com/en-us/data/ff707264.aspx) for some more insight.

Good luck!

edit: Even if you decide not to use EF for some reason, do be sure to dump the datasets :)

Fredrik Hu 2010-05-22 22:30:30

Hahahhaa, you made me laugh with datasets comment...I'm in process of doing so :)

Wally 2010-05-22 22:34:03

ansaurus

tags:

views:

answers:

.NET Database application guidance.

related questions