views:

460

answers:

9

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 LINQ to SQL for various reasons. I want to build upon this and create our own in-house ORM, again for various reasons. In the past I've always had the Data Access Layer already built so was never involved in building....

+2  A: 

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.

Michael Maddox
I don't mind using LINQ, but where it adds benefit and not just because.. (LINQ to SQL, is a no go). I would assume DataSets will be required as I need to batch statments and so return multiple tables.I plan to use CodeSmith, but writing my own code to generate the template structure etc..I want to use stored procedures so e.g.CompanyListCompanyGetByIDAddressListAddressLisyByCompanyIDBut I will batch statments based on context (eager loading).Don't want to use SubSonic, EntityFramework, or NHibernate have used in the past seem very bloated, and Team lead here is a no go with them.
I think CodeSmith is a good option for you. The most likely thing to help you is to find some CodeSmith templates that do something similar to what you want and start there. Sorry I can't be of more help than that.
Michael Maddox
+6  A: 

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.

John K
Yes I agree many people have created ORM's and while I agree there are a lot of advantages I am in a situation where the team lead is not a fan of them.I used a code gen at my previous company and it was very helpful, so I have a strong idea of how it would piece together and how to approach the obvious issues of like eager loading, lazy loading etc. However, its the basic Sql data access i am after as even after 5 or so years of .NET.. haven't really had to ever do it.
Yes, sounds like you're well versed in the necessities. The DAL and ORM are often closely related and choices for one will likely affect the other. The best advice I finally offer about DAL is - whatever choices your team ends up making - use programming interfaces to abstract away the details to allow for flexibility in that whole region in the future. Many other responders here have outlined more practical advice about speaking directly to DAL and ORM implementations. BTW I think it's a really hard questions for any of us - always will be.
John K
A: 

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.

Tim Saunders
+1  A: 

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.

Andrew
+1  A: 

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.

Chris
A: 

Before you can make your decisions there are some questions that you have to answer to yourself before begin, not just if you dont want linq or ms data access layer those are some of that questions:

  • Do you want to be able to modify the code (generator) or do you want a DAL that gives you the service of accesing the DB?
  • Do you want to deal with XML configuration files or do you prefer a DAL based on reflection?
  • Do you want support for multiple DBs or you can live with an specific one?

Some years ago I had to build a DAL for the company I was working for and resulted that it was easier than I though, the result was an ORM based on reflection who supports many DBs at this time SqlServer, Oracle, PostgreSql and SqLite, I can share the code for you it may help you build your own or extend it to your needs.

If it helps you for anything build your own DAL (if you havee the time) its a great learning experience you will learn some Sql and several features of the language that you might never use again.

Good luck with that...

I would use an XML file, that is what I used at my previous company as a mapping - Worked very well.If you have code to share that would be very helpful to me and Im sure others as a starting point.. kitkat _ robins (at) hotmail dot com
Would you be able to send me please?
A: 

Check out DbExtensions, you can use it to simplify DAL code, or you can build your own ORM on top.

Max Toro
+1  A: 

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

Amr ElGarhy