I would like to konw what is considered the most elegant C# .NET method to produce a Data Access Layer?
I am using MyGeneration DooDads. Is this an elegant solution?
Is it still acceptable to use the CRUD Stored Procedures + DAL Library for data access with .NET Entity Framework and NHibernate ORM tools?
You can try to use domain model with ORM (Linq or Nhibernate). Visual Studio has a good support for Linq, it is easy to configure and use. All data access methods are encapsulated in the domain objects (data table objects) and all the query result is strong typed.
There is no answer to this question; everybody has different opinions.
Personally I like ORMs for simple home projects but wouldn't go near one in an application I actually have to support, and much prefer to use stored procedures to give the database a well defined interface that is abstracted from the storage mechanism.
Many people disagree with this point of view. Heck, even I'll probably disagree with it in a few years time. But it doesn't really matter what I think or what they think, if you're happy with what you're doing and find it efficient to code and easy to support, then it's elegant.
Related
I'm getting ready to start a C# web application project and just wanted some opinions regarding pulling data from a database. As far as I can tell, I can either use C# code to access the database from the code behind (i.e. LINQ) of my web app or I can call a stored procedure that will collect all the data and then read it with a few lines of code in my code behind. I'm curious to know which of these two approaches, or any other approach, would be the most efficient, elegant, future proof and easiest to test.
The most future proof way to write your application would be to have an abstraction between you and your database. To do that you would want to use an ORM of some sort. I would recommend using either NHibernate or Entity Framework.
This would give you the advantage of only having to write your queries once instead of multiple times (Example: if you decide to change your database "moving from mssql to mysql or vice versa"). This also gives you the advantage of having all of your data in objects. Which is much easier to work with than raw ado Datatables or DataReaders.
Most developers like to introduce at least one layer between the code behind and the Database.
Additionally there are many data access strategies that people use within that layer. ADO.NET, Entity Framework, Enterprise Library NHibernate, Linq etc.
In all of those you can use SQL Queries or Stored Procedures. I prefer Stored Procedures because they are easy for me to write and deploy. Others prefer to use Parameterized queries.
When you have so many options its usually indicative that there really isn't a clear winner. This means you can probably just pick a direction and go with it and you'll be fine.
But you really shouldn't use non-parameterized queries and you shouldn't do it in the code behind but instead in seperate classes
Using LINQ to SQL to access your data is probably the worst choice right now. Microsoft has said that they will no longer be improving LINQ to SQL in favor of Entity Framework. Also, you can use LINQ with your EF if you should choose to go that route.
I would recommend using an ORM like nHibernate or Entity framework instead of a sproc/ADO approach. Between the two ORMs, I would probably suggest EF for you where you are just getting the hang of this. EF isn't QUITE as powerful as nHibernate but it has a shorter learning curve and is pretty robust.
I would like your opinions regarding "DataSet Designer" and DAL (Data Access Layer) best practices.
I use Visual Studio 2010 Framework .NEt 4.0.
For my understanding "DataSet Designer" allow me to create automatically strictly Typed-DataSet with DataTable and Adapter, this consist in DAL directly in Visual Studio 2010.
I would like to know:
- If in real scenario "DataSet Designer" is working well, or is better write Custom Business Object.
- If exist other new solution introduced in .net 4.0
Thanks for your support! :-)
I have to work with typed datasets and it is a nightmare. If you have an option never use them. Everything is better.
With the advent of the .Net 4.0 framework and the introduction of LINQ to SQL, I've been adopting a customized DAL of strictly written business objects. We experimented with Entity Framework briefly, but ultimately concluded that it is very similar to DataSets in that the auto-generated code, while handy, is just too bloated with extra junk that we ultimately didn't use.
We've found that writing LINQ into our DAL and extracting data pulls into our custom classes, we are able to streamline our data access and control the usage of the data functionally. It has been a very handy process, but it has taken a little bit for the junior developers to grip onto it.
I would suggest a ORM like Entity Framework or Nhibernate.
Data Sets smells too much to database way of thinking and I personally had a lot of problems working with them. They just get broken quite often and throw weird errors that are hard to troubleshoot.
Some other related questions you may find interesting
What are the advantages of using an ORM?
ASP.NET DataSet vs Business Objects / ORM
Use ADO.NET Entity Framework, which is where the future of Microsoft's ORM is going. Or, consider an open-source one like NHibernate...
HTH.
At my company we've been using Typed DataSets for a little while now, and have had a generally positive experience. I understand that many people don't like DataSets, and there are certainly newer data access tools out there, but since you asked about a real-world scenario, here are some of my requirements and findings:
Need to be able to read SQL Server, MS Access, and FoxPro data sources
SQL Server access is only through SPROC calls (not my choice)
Relatively easy to learn, especially to developers new to ASP.NET
I've personally explored low level ado.net access, typed datasets, linq-to-sql, and simply writing custom data access classes. I have not looked at the Entity Framework yet, as the version included in VS2008 seemed to have some mixed reviews, and I did not have access to VS2010 until just recently(I do plan to review EF sometime this year yet).
We chose to use Typed DataSets because they seemed to offer faster development against SPROCS and we found a very comprehensive tutorial by Scott Mitchell on the asp.net site: http://www.asp.net/data-access/tutorials.
As to our experience thus far, it has mostly been good. The DataSet designer generates a huge amount of code even for small number of Tables (<20). Making changes in the SPROCS has caused a few headaches, but I'd like to be shown a tool that would make this easier.
One thing you might try to make your decision easier: Come up with a small domain problem like a customer edit page or order entry page, and implement it multiple times using a variety of technologies. It takes some time to do this, but it is a good way to learn and you can compare the technologies for yourself. We did this and it seemed to help a lot.
I will personally prefer custom business objects with their flexibility but its more work. Also look at with Entity Framework and Linq To Sql. Entity Fx has got a lot more flexibility in .NET 4.0. This article should get you started on Entity Fx.
If anything I think you should look into Entity Framework. There are lots of great tutorials out there to get you started.
I personally agree with Joel Etherton, conditionally.
If you have a small enough project that even with EF's bloat you're still not looking at too much shenanigan-code, I would say the expediency it offers is worthwhile. However in larger codebases, it can become a lot to get your hands around so much bloat.
The other benefit to EF vs older style business objects which goes unmentioned though, is with EF implementation you will probably get easier upgrades to newer .NET versions taking advantage of benefits in the next .NET without having to rewrite a bunch of code by hand. (This can also be a double-edged sword as upgrading to new .NET with EF may affect the behaviour of your dal as opposed to a hand-written dal is less likely to be so affected.)
That said, I agree with Joel Etherton, write the simplest smallest dal you can implementing LINQ, the dal is always too important to make overly-complex whenever it can be avoided.
If you do not want to waste you time do not learn DataSets. Study general concepts of object-relational mapping, their pros and cons. Look at projects like Hibernate for Java or Doctrine for PHP. Approaches behind DataTables and DataSets which provide just wrapping of database objects is over. Your framework should guide you to design you domain model, not the database schema.
NHibernate. Especially if you are using Oracle.
Can you recommend a DAL object creator that is simple yet useful. I want something that creates and updates object the way LINQ does. It should be in c# and much better if it splits object's properties and data access methods in partial classes.
We've used CSLA before but I want something more simplier for our next project.
Thanks in advance
Just a humble recommendation as there are plenty of great products out there - we have been using EntitySpaces (an ORM) for a couple of years at our shop and like it.
If you are looking for an ORM, see here:
NHibernate, Entity Framework, active records or linq2sql
Are you just looking to use raw ADO.NET and also maybe datasets? If so, do you want a code generator to generate your data layer for you without a full blown ORM?
If you want to use Linq (not Linq-To-Sql), then you need an ORM at this point.
CSLA is not really an ORM and doesn't really do much from a data layer perspective. It is more of a business layer tool.
I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
I've searched the internet and found some samples for this but I never know which is the best approach.
Is it to make [Attributes]? Or use <Generics> or something else?
So please just give me a head line and I'll go on from there.
Thanks again and forgive my language.
Just make sure you:
Always use stored procedures
Never use stored procedures
Sometimes use stored procedures
Use nHibernate
Use SubSonic
Use Entity Framework
Write your own
Never write you own
Use POCO
Use ActiveRecord
Use IRepository
Always do what Fowler says
Never do what Fowler says
Don't use Linq to SQL, it's dead
Use Linq to SQL, it's no longer dead
Do all that and you will be fine.
Best approach is:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
ORMs are incredibly hard to get right and a huge undertaking.
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/
I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.
If you are a starter I would recommend use of SubSonic (more so if you are on web development).
as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.
Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
Marc
Please read Data Access Layer Design Considerations
Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.
Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/
Came across this:
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp
And wondering if this is the right solution as I am not that big of a fan of creating a class for every stored procedure or do I use Enterprise Library for ASP.net 2.0 project.
You definitely shouldn't be creating a class for every stored procedure. There are a number of approaches you can take to handling your database interactions. You should have a good look at the major frameworks out there and decide which one best suits you. The Castle Project solution is great, and relies on nHibernate (nHibernate). LINQ is a similar offering by Mircrosoft (LINQ Project). Both of these solutions are full ORM frameworks (Object Relational Mapping) and will generate dynamic SQL to persist your objects in the database. Each also has it's own quirks and likes you to structure your objects in particular ways. If you don't want to manage the SQL your system uses, I would definitely recommend one of these approaches.
I come from a database background, and prefer a bit more control over my SQL. In particular I like to have my interractions handled by stored procedures. I find this enables me to control both the SQL better for optimisation, but helps me manage database security in a more friendly manner. To accommodate this approach, I recommend something like iBatis (iBatis). iBatis isn't a full ORM, but rather a simple SQL mapper. The downside to my approach is that you need to write a lot more code (SQL), but I don't mind the trade-off.
Is there any possibility of upgrading to framework 3.5? if so take a look at LINQ to SQL and Entity Framework as this will accomplish alot of this for you.
If not then as long as it generates standard code that doesnt tie you into 3rd party libraries then you could certainly use it. At my workplace we have our own generator similar to this and it works well although we will shortly be moving to LINQ to SQL.
There are many ways of wrapping a database table in a C# class; you probably want to investigate a few alternatives before choosing between the one you've linked to and the Entity Framework.
There's a software pattern called the "active record pattern" which describes exactly this approach - one C# class for each table, with load/save methods like Customer.GetById(), Customer.Save(), and so on.
For ASP.NET 2.0, check out the Castle Project's ActiveRecord implementation and a third-party Visual Studio plugin tool called ActiveWriter that lets you generate class wrappers for your tables using a drag'n'drop interface.
You will need to determine at what point you need sets of data that are composed from your tables, and whether you want SQL to produce these with stored procedures or if your business logic layer will handle these. As Dr8k says, nHibernate will create SQL for you, but there is a learning curve with nHibernate. The ORM will be in control of how you are getting the data and depending on your environment and DBA's conmfort level you may other issues to overcome.
If you more comfortable with SQL, then there is another tool called SubSonic that will create wrappers ala Active Record for you while offering you the ability to use stored procedures as well. There is also a nice query tool with a fluent interface that you can use if you are not able to use LINQ.