Creating My Windows Form Application and using ADO.Net as Data Access layer and
SQL server as my Back End with lots of SP's.
Do i still stick to ADO.NET or go to studying FnH or Linq to SQL? Which shall i choose? Or i still stick in ADO.NET?
Can you give me Recommended WebSites on EF or FluentNhibernate for kick of tutorials..
Thanks in Regards
It's really just up to you to pick one - they're all valid technologies.
If you're already familiar with the low-level ADO.NET constructs, and you don't feel like putting the time into learning a different methodology, you can stick with plain old ADO.NET - this is not going away anytime soon.
If you want to start off with a very simple ORM, I would suggest LINQ to SQL. However, Microsoft has basically left LINQ to SQL in the dust in favor of Entity Framework, so if your project has long-term maintenance concerns, LINQ to SQL may or may not be the best choice. It is a really nice, lightweight, easy-to-use framework though...
If you want to learn the latest MS data access technology, you could try Entity Framework. The initial setup is not too bad, but Entity Framework is a beast, so there might be a bit of a learning curve at some point, if you run into something that works differently than you expect, or you want to learn more. EF is fairly full-featured at this point, but it still lacks some of the functions offered by more mature data access technologies like NHibernate.
Finally, if you want to try something different than the Microsoft offerings, NHibernate is a great framework. You're not going to find the entity designers, property pages, wizards, hand-holding, and stuff like that, but that's almost the point of NHibnerate. In Fluent NHibernate, the primary focus can be on your domain code, and less on the database, which makes it very conducive to unit testing. Entity Framework has gotten better with persistence ignorance, but it still feels a bit heavy-weight compared to NHibernate.
In addition to these, there are several other solid data access technologies that you could look into, but I hope this gives you some info to start with.
Related
I have been stuck in 2.0 for some time now due to what my job requires and I am trying to now keep up with the latest .net framework. I am begining to build a Mvc application and I am wondering if the Data Access Application Blocks (SqlHelper) is still an acceptable method of writing a data tier.
I know there is a lot of debate over the EF, with it's speed performance, lazy loading and the issue of keeping the database separate from the application. So I hesitate to go there right now.
But I am seeing a lot of code that just uses ADO.Net and the DataAdapter and wondering if there was a shift back to ADO.net without a helping framework. If this is correct then my question would be why? It seems like a step backwards to not use some type of helper class/framework to do data access.
The use of ORMs is seen as best practice these days, and the Data Access Application Block has fallen out of favor as other, easier to work with libraries have come to existence and prominence in the .NET world.
These would include nHibernate, LINQ to SQL, Entity Framework to mention the big, fully featured libraries (some more fully featured than others).
People who do use ADO.Net directly are those who want more control over their SQL than afforded by these (always possible with ORMs, but they tend to be rather cumbersome when it comes to accessing the database not through their idioms).
An example lightweight ORM is Dapper, which is a very thin layer over ADO.Net.
I use ASP.NET with a informix database.
I use a set of written classes to handle the connections, the CRUD operations, transactions, etc....
Now, I feel these classes are not the best choice, less performance,take a lot of time and have many drawbacks.
I want to use an ORM, but I don't know how to choose the one which suits my web applications (ASP.NET, Informix).
Please help to select the convenient ORM.
I'm confused among nHibernate, Entity Framework, LINQ To SQL, and the Open Access (Telerik Component).
Note: I will use Visual Studio 2012 so I want the recent comparison.
I'd really suggest Entity Framework, as it is the native framework of .NET. Here it is stated that an Informix provider is available for EF.
Have you thought about using Fluent NHibernate? There's a wealth of articles on the web for it, and plenty on SO!! Here's one such article : converting to Fluent NHibernate sessionmanager.
EDIT :
Been thinking about your situation and I'll tell you how I usually think. Firstly, I'll think about exactly what it is I want my Gateway layer to do (this is the layer I use to talk to the persistance medium). Now, most will say, I want it to talk to the database or I want to insert and update stuff. But recently, I have found this isn't enough! Halfway through coding a gateway layer with these questions in mind, I suddenly realised that I wanted to do something ever so slightly different, and boom, I couldn't do it using NHibernate very easily. So, I made a few concessions and went with Linq-ToSql as it supported what was a higher priority requirement over some of the niceties of NHibernate.
Now, the reason for my tale is this : NHibernate provides some great little features like Result Transformation. I can have a view on my Db with masses of joined tables, giving an aliase for each field and with a lovely result transformer, bang, it's instantly transformed into my DTO. Now, don't get me wrong, Linq-To-Sql has a similar thing with the auto-generated classes. But I don't want these visible outside of the gateway layer (another conversation). Equally, Linq-To-Sql handles transactions with ease - something I thought NHibernate didn't do so well!
So, it all boils down to : what are my EXACT requirements within my gateway/repository layer and what technologies are compatible with my persistance medium?! And now, I can think about what technology I want to use.
I realise I may not have answered your question per se, but I hope it has given you something to think about!
Happy coding,
Cheers,
Chris.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0903linqentity/
The link above will provide you with links to download the informix provider, as well as take you through a step by step process of using the informix provider in conjunction with Entity Framework.
More about Entity Framework
http://msdn.microsoft.com/en-us/library/aa697427(v=vs.80).aspx
Simply put, once you have this set up you will be able to create classes that map to your informix data structures and perform queries using linq. EF is quite a powerful and useful tool, I recommend it.
My vote is with Fluent NHibernate - you get the configurability and cross-platform usage of Hibernate but you get to obviate the necessity of using massive XML configuration files. Entity Framework is good, but I don't like tools which rely too much on IDE/Designer support.
Happy coding,
Mel
I'd recommend Fluent NHibernate. Personally I see it used in more companies than any other ORM framework.
I've used Entity Framework, both design-first, which has serious lock-in drawbacks, and code-first, which is okay.
I posted an answer on Code Review when someone was asking an almost identical question.
i think its better to read this book first :
http://www.wrox.com/WileyCDA/WroxTitle/Professional-ASP-NET-Design-Patterns.productCd-0470292784.html
What is a good ORM to use for rapid prototyping without the hurt?
I've used LINQ-to-SQL with great success, but I always end up building a whole repository layer around it (and everything that entails) so I don't have to put "Insert/Update" and mapping logic in my controllers. If I want to add a column, I have to write migrations and update interfaces and repositories.
I'd like something that just works. db4o is a good candidate, but I've always had gripes with the lack of proper data paging and the cringing primary key support. So let's narrow it down to a SQL-based solution that works with SQL Server.
Which ORM can build a relational SQL database with the least amount of configuration or code?
Entity Framework is quite nice and with the latest release you get some nice features like Code First and POCO entities.
I would look at Fluent NHibernate as it is really quick to pick up and the fluent configuration is nice.
Entity Framework / Linq2SQL have the shortest time to market. NHibernate is a little more complicated.
I'd go with NHibernate anyway. When things get more complicated, it gets harder slower if that makes any sense.
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.
In Java, Hibernate is king in terms of automating code/DB synchronization. And I'm aware NHibernate is a .NET equivalent, and that LINQ has some cool SQL functions (despite not being developed further IIRC).
But, is there any advantage from pairing .Net development with a SQLServer database? Magic automatic persistence of objects perhaps? Or these days does your language/DB pairing make little difference?
A simple pairing of .NET with SQL will afford you nothing over a good ORM.
The only possible reason to use the two together is that both come from the same vendor and will certainly inter-operate well.
That's why Linq2Sql came about, not after NHibernate (Hibernate for .NET) has been around for years.
Being the data layer is supposed to abstract the DB you choose, any intentional built in advantages would increase coupling and defeat the purpose of abstraction.
I'd say try and use what you know, if that's SQL Server go with that. You don't get free magic automatic persistence of objects with .net+sql server you'll have to combine it with something else. Big benefit of .net + sql server is it's all MS so it will to fit together and there's a massive community to call upon if you need assistance (most other DB's also have large support communities as well).
ORM frameworks are very popular and there's loads of them available for most databases. We use LINQ2SQL because it works for us. Other developers I know use EF, Subsonic and NHibernate.
Perhaps you can play/review a few ORMs and see if any have killer features that you'll use or stand out due to the configuration, ease of use, features or something else that you like.
Considering the "in terms of ORM" part of the question, the only synergy I see between a .NET application and SQL Server is through Linq to SQL.
With Linq to SQL you'll essentially get a better integration of ORM tools into Visual Studio (fancy entity designer, custom templates...) and of course Linq querying. I'm not sure if that's worth the bother though, since Linq to SQL is and apparently will remain really limited compared to the big ORM solutions.
Other benefits are really specific and not especially related to ORM, such as a better fit with the CLR stored procedures available since SQL Server 2005.