Simple Data Access Layer

Question

Can anyone suggest a simple Data Access Layer (C# .NET)? Not keen on using the Microsoft Application Data Access block, seems very bloated and overkill. Also don\'t want to use

Answer 1

Here is a complete list: ORM tools ".Net"

ADO.NET Entity Framework, Microsoft’s ORM (released with .NET 3.5 SP1)
Base One Foundation Component Library, free or commercial
BCSEi ORM Code Generator, free or commercial
Business Logic Toolkit for .NET, open source
Castle ActiveRecord, ActiveRecord for .NET, open source
DataObjects.Net v4.0, open source, commercial
DevForce, commercial, N-Tier
Developer Express, eXpress Persistent Objects (XPO)
EntitySpaces, commercial
Euss, open source
Habanero, Free open source
iBATIS, Free open source
Invist,free ORM and code generation tool
LLBLGen, open source drivers, commercial
LightSpeed, free or commercial
Neo, open source
NConstruct, commercial
NHibernate, open source
Opf3, free and commercial
ObjectMapper .NET, GPL and commercial license
OpenAccess, free or commercial TierDeveloper, free ORM and code generation tool
Persistor.NET, free or commercial
Quick Objects, free or commercial
Sooda, open source; BSD license
Subsonic, open source
Orasis, free trial or buy.
Telerik, express or buy.
CSLA.NET, free.
ECO, free or commercial
nhydrate, open source
.netTiers, open source
dapper-dot-net, open source
codesmithtools plinqo, open source

Answer 2

Have a look at SubSonic version 2.x if you need to avoid linq. This is a simple/ lite ORM that you can build upon. Why roll your own when there is great code like this.

Answer 3

For very simple requirements (and I mean simple!) I'd create a DAL based on the repository pattern, where the sql querying is done in the repository methods and then simple POCO's (Plain old CLR objects) are created and returned.

You can call sprocs or parametized SQL if required. Then map the data to your poco (for this just use a standard SQLDataReader)

But to be honest the moment the queries get big or complex or there are lots of fields in your objects you're better off letting a proper DAL/ORM take the strain and concentrate on your application.

Answer 4

Do you want to be able to use Linq?

Do you want to use DataSets / DataTables?

Do you want to use a code generator (of your own or someone else's)?

Do you want to use stored procedures?

Honestly, it's not that hard to grow your own DAL/ORM from scratch as long as you don't care for advanced features of any sort and you don't mind the mind numbing tedium of the process. You have to be a little crazy though. :)

I'm assuming you don't want to use anything like SubSonic, EntityFramework, or NHibernate as well, but correct me if that is a bad assumption.

Answer 5

Other individuals and organizations have spent months or years developing their own ORMs and technologies -- many of which you listed -- and many are free to use. You should devote your resources toward your core application logic instead of trying to build another whole beast called ORM. There are enough offerings out there to satisfy all kinds of applications.

You said you've never been involved in building your down DAL. It's a classic starting error to try to roll your own resulting ORM (as far as time and resources, not necessarily knowledge), for those reasons stated above. If you think some of the existing offerings seem overkill, just wait until you get into the intricacies of building your own.

However if you want to compete in the ORM market and that IS your product, then go right ahead. That's my 2 cents.

Edit: If you have concerns about being bound to a certain ORM product or offering in your project, you can simply hide away whatever software you choose behind an interface and swap in other ORMs as needed...

public interface IBusinessDataOperations {
   // hides any ORM of choice
}

And if someday you have some free cycles and want to build your own ORM, even after trying other products, you can just slip it in behind this interface too.

Answer 6

Actually the simplest SQLHelper file that I've found has been the early 2000 era MS Data Access Application Block. After unpackaging and opening the solution you find that you have just one file called SQLHelper.cs which basically just wraps alot of the raw ADO that you would be writing with a home grown DAL. It is best practice code (at the time yes) and easily converts to .net 2.0 framework and above. After you place SQLHelper into your solution, then you can easily add in your own data access components to do your basic CRUD work, but you won't have to worry about the low level coding of opening a connection or a dataset or whatever.

I know what you're thinking, why suggest this because you said you didn't like the blocks. Well this one is the only i've found that doesn't use a provider factory and all of that extra code that you're saying is overkill. This block is only for SQL Server so do keep that in mind. But overall, you might find that this is a good starting point in your project.

Here is a download link to the block itself.

Good luck, and hope this helps.