I'm still quite new to NHibernate and most of it I'm getting to grips with. One area that I'm really lacking a proper understanding of though is querying (at least when it comes to anything reasonably complex).
I learn best by example, but I feel that I haven't really been able to find all that many in depth querying examples on the web. There are there are quite a few of course - but there are many different techniques and approaches, and most of the examples seem to gloss over the details.
(For instance in the official nhibernate documentation, the ICriteria explanation comprises 4 sentences!)
Maybe I just haven't looked well enough? ;) Does anyone know of any good resources (on the web) with lots of query examples? (Both HQL and ICriteria prefferably).
StackOverflow. I'm serious - go into Hibernate and NHibernate tags and search for Criteria and / or HQL. There are tons of questions / answers. I know because I wrote a lot of them :-)
NHibernate manual sections on HQL and Criteria have quite a few examples as well.
Finally, you can always post a question if you're having trouble with something. When / if you do, be aware that posting appropriate mappings / classes / tables makes it a lot easier to understand / answer any question related to Hibernate queries.
Related
I am in process of evaluating ORM first time. Please suggest which one i should choose for my next project.
I wrote couple of sample code with EF 4.1 code first. Before start same exercise with Nhibernate, I want to know if somebody have already experience with both in production application.
My evaluating criteria
Speed of database access
Learning curve (because I am new to ORM)
Community support
Tutorial/Books availability
Anything else which I should consider (Because I am noob to ORM)
I wish if people who have experience with both the ORM in production level app answer my question.
Thanks in advance!!!
I am aware that this question may be a little bit dangerous to ask ;)
Having used EF 4.1 and Castle ActiveRecord (based off NHibernate), I would rate them as follows:
Speed of DB access - NHibernate for anything remotely complex, otherwise about the same. The problem with EF is that it creates such convoluted SQL that it's difficult to know how to optimise it or if it's even possible to do so.
Learning curve - I personally found EF easier to get started with, but others may feel differently, and both certainly have a learning curve.
Community support - Depends on what you mean by 'support'. You'll find lots of info on the web (and this site) for both. NHibernate is open source, while EF is controlled by MS.
Tutorials/Books - I believe there are more 'official' resources available for EF at this time, but searching on forums will likely get you what you can't find in books.
Anthing else - Realize that the purpose of ORM's is to simplify the data access layer for the developer. However, both of these ORM's (and pretty much every other heavyweight ORM) expect you to use certain coding patterns for this simplification to be realized. While coding pattern enforcement isn't a Bad Thing (some would argue that it's a must), it's something you certainly need to prepare for before choosing one.
If you are a noob to ORM and only need the basic features you may find the Entity Framework and Nhibernate are over kill and should be looking at a light weight one like Massive:
https://github.com/robconery/massive
That said there are two main issues you face with EF vs NH
EF is all that microsoft support and so all their tooling by default uses EF. Making beginner code easier with EF.
NHibernate is more mature and has a greater feature set (if you need it) also has a good development community and lots of blog info about it.
I would choose Massive if you want simple / fast but unsupported, EF if you want easy and MS support but limited in some ways, or NHibernate if you have the time to learn a proper ORM.
Hope this helps.
Well im my personal experience Nhibernate have been the right choice, in complex situation have given me better time results, and it was a lot easier to learn.
I learned it first and then tried the Entity Framework and I found it easier to learn nhibernate Even though in that moment i didn't knew anything about ORM.
Community support and Tutorials and books I can say they are both good and have a lot of material to learn from.
Now I can use them both but still likes Nhibernate a lot more.
New year - new startup :)
We are chosing ORM. I personally worked with LLBLGEN last years.
I've looked through EF4 today and have found that its functionality is close to llblgen.
(filtering, sorting, grouping, working with stored procedures and functions, working with graphs of objects (prefetch path), lazyLoad).
I know that llblgen doesn't support POCO, that means that it is required to write additional (or more complex) code to decouple it from Domain.
I don't think that llblgen license is con as llblgen is real successful alternative to Microsoft's orms and it is cool that we have such alternatives.
I didn't find any concrete comparison of these orms in stackoverflow.
Just something like "If it is not critical to pay maney then use llblgen" :).
So I just want to list pros and cons of LLBLGEN and EF4. (ORMs functionality only without designers features)
I have used LLB on several projects over the last few years and I am just finishing off my first EF4 project.
Both are perfectly fine for simple 1-1 mappings between objects-tables. Doubtless other people would disagree, but for projects where I use codegen I try and keep that the case as far as possible.
I'm no EF4 expert, so theres probably things it can do that I've not discovered yet but I feel that LLB is a more mature product and the support is absolutely fantastic.
Surprisingly enough getting help on EF4 is nowhere near as easy and googling for the answers can be difficult because you end up with loads of unrelated C# hits. The LLB forums tend to give you detailed answers to your code snippets very quickly - normally within hours.
But MS being the huge beast that it is I had to give EF4 a try on a project, and things have worked out fine. But personally I still prefer LLB.
Pro for LLBLGen - support. Very responsive support forum with issues typically fixed in a day or 2 (or sometimes hours)
Try getting that level of support for EF (or any other ORM come to that !)
Ok guys. Let me summarize my question after studying EF4.
It is possible to use EF4 with POCO objects that is good if you are working with Domain model. LLB doesn't support POCO.
LLB entities has state even without dataContext (Adapter scenario). It means that you can get entity in one context and save it in another and second context will know that entity is not new. EF4 will treat it as new Entity and it is require to write additional code to mark it as updated.
LLB has SelfServicing scenario that is good for small applications as entities have self saving and lazy load functionality.
As mentioned above, LLB has great support. It seems the rule is to answer during 8h in workdays and 24h in weekends.
LLBLGen is so mature that it generates about six times as much code as necessary. Keep in mind that its first of many confusing and overcomplicated APIs had been designed long before the introduction of generics and LINQ and it shows. Starting a new project using LLBLGen is only understandable if you have already invested years in learning it. In all other cases do yourself a favor and forget it ever existed!
I am going to try using NHibernate, the reason I stayed away from NHibernate so far was the xml-mapping part. Now that (I found out) there is fluent nhibernate, looks like we don't need to do xml mapping.
But I am wondering if starting with some xml mapping, would be more helpful in learning and getting comfortable with NHibernate, or should I start using it with fluent for nhibernate?
cheers,
hazim
I had similar concerns when I started with nHibernate, but having taken the road of learning the mappings and then learning Fluent, I have to say I wish I had just started with Fluent.
My reasoning is that there was enough to digest just learning nHibernate and Fluent helps make nHibernate more simple. Having said that I agree with David M, you'll need to understand the mappings at some point.
This series was really useful when I was learning nHibernate.
HTH
I would actually recommend attacking NHib from a totally Fluent perspective right now - FNH has matured just enough to not drive you nuts with inconsistencies, there are a lot of decent learning aids out there (try and look at anything posted since Sep 2009 on at first), as well as a decently active user group.
I found this amazingly good and very recent video tutorial Vacation of Fluent NHibernate, conceptually based on the Summer of NHib series everyone else has here. Unfortunately the author just got a new job and hasn't yet completed the series, but I will be shocked if you don't find it incredibly approachable and useful as a learning tool all the same.
You also can fairly easily learn to generate the HBM maps, and reading them is way more useful IMO, and certainly less painful, than writing them at first.
Lastly, give yourself a break and don't expect to master any of this by the end of the week! If you spend some time with FNH first, you will know which areas of NHib you want to dig into eventually and feel less overwhelmed by it when you do.
Cheers,
Berryl
Suggest you get started with a simple database schema using Fluent's auto mapping, so you can get used to using NHibernate Sessions and SessionFactories properly. Then you can branch out. But at some point you will need to fall back on XML mapping, so it's worth looking at eventually.
For understanding what is going I'd recommend starting with XML Mapping files. When learning NHibernate I found hand building configuration files to be useful. That said after I was comfortable using fluent and the occasional mapping file builder has been great.
For learning NHibernate though it's targeted at a previous version the Summer of NHibernate is incredibly useful.
Start with the XML mappings. Fluent is getting closer to being feature complete, but the terminology it uses still diverges from the terminology within the XML mappings (which is what is used by most NHibernate tutorials / documentation). Once you've done a mapping or two, it really isn't that hard especially with intellisense support from the schema files.
Fluent NHibernate is great, but for a beginner I think it might lead to some confusion as you cross reference your mappings with online research.
I've been successful with writing my own SQL access code with a combination of stored procedures and parameterized queries and a little wrapper library I've written to minimize the ADO.NET grunge. This has all worked very well for me in the past and I've been pretty productive with it.
I'm heading into a new project--should I put my old school stuff behind me and dig into an ORM-based solution? (I know there are vast high-concepts differences between NHibernate and EF--I don't want to get into that here. For the sake of argument, let's even lump LINQ with the old-school alternatives.) I'm looking for advice on the real-world application of ORM type stuff against what I know (and know pretty well).
Old-school ADO.NET code or ORM? I'm sure there is a curve--does the curve have an ROI that makes things worthwhile? I'm anxious and willing to learn, but do have a deadline.
I find that LINQ to SQL is much, much faster when I'm prototyping code. It just blows away any other method when I need something now.
But there is a cost. Compared to hand-rolled stored procs, LINQ is slow. Especially if you aren't very careful as seemingly minor changes can suddenly make a single turn into 1+N queries.
My recommendation. Use LINQ to SQL at first, then swtich to procs if you aren't getting the performance you need.
A good question but a very controversial topic.
This blog post from Frans Bouma from a few years back citing the pros of dynamic SQL (implying ORMs) over stored procedures sparked quite the fiery flame war.
There was a great discussion on this topic at DevTeach in Montreal. If you go to this URL: http://www.dotnetrocks.com/default.aspx?showNum=240 you will be able to hear two experts in the field (Ted Neward and Oren Eini) discuss the pros and cons of each approach. Probably the best answer you will find on a subject that has no real definite answer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I've never had much need for programming with databases. Since their use is so widespread it seems like a good thing for me to learn. SQL seems like the place to start, possibly SQLite and maybe the Python bindings. What would you recommend for someone new to this? Libraries, tools and project ideas are all welcome.
Structure Query Language (SQL) is the language used to talk to database management systems (DBMS). While it's a good thing to learn, it's probably best to do it with a project in mind that you'd like to do. It's funny you say you've never had a need, because I'm the opposite, almost every program I've ever written has used a database of some sort. The vast majority (mostly web-based) revolve around using a database.
Learn about relations and database architecture. This means how to structure your tables, make foreign keys and relations.
For example, you might have a movies database. In it, you store information about the Movies, Studios that released the movies, and the Actors in the movies. Each of these becomes a table. Each Movie is released by one Studio. Since you don't want to store duplicate the studio information (address, etc) in each Movie entry, you store a relation to it, so each Movie item contains a reference to a Studio item. This is called a one-to-many relationship (one studio has many movies). Likewise, you don't want to store Actor information for each Movie. But one Actor can be in many Movies, so this is stored as a many-to-many relationship.
Learn SQL itself. SQLCourse is a good place to get started, but there are many other books and resources. SQL is a standard, but each RDBMS has its own vendor-specific ways of doing certain things and other limitations (for example, some systems don't support sub-queries, there are several different syntaxes for limiting the number of rows returned, etc). It's important to learn the syntax for the one you're using (eg, don't learn Oracle syntax and then try and use it in MySQL) but they are similar enough that the concepts are the same.
Tools depend on the DBMS you use. MySQL is a pretty popular database, lots of tools are available, and lots of books. SQLite and Postgresql are also quite popular, and also free/open-source.
If you can, you really want to find someone who knows how to use it, and pick their brains. That's because there are a lot of important principles (eg 3rd normal form) which will are a lot easier to learn through discussion rather than from books.
If you want to teach yourself, you should learn the syntax for doing basic selects, joins, updates, deletes, and group by queries. You should also learn the "Swiss army knife" of selects, the CASE statement. Too many people don't. Many of the tutorials recommended in this thread will do that. Then you need to try to solve SQL problems. I'm sure that Joe Celko's SQL Puzzles and Answers is a good source of them, though it may be a little advanced.
This will let you actually write SQL. But you still need to learn how to organize a database. Which for most purposes means that you really need to learn what 3rd normal form looks like. You don't have to be able to give a formal definition of it, just recognize it when you see it, and know how to adjust something to be in that format.
Lots of references will explain it, but you won't know if you're reading them correctly. This is where it really, really helps to have access to someone who can look at a table layout and tell you, "That's right" vs "That's wrong, here's what needs to be changed." Failing all else, you could post a question here with a proposed layout. But a back and forth discussion with a live person would still be preferable IMO.
Try Wikipedia, http://www.w3schools.com/sql/default.asp and http://www.sql-tutorial.net/ Also check YouTube for SQL Videos.
You are correct, SQLite is a great place to start because it is free, lightweight, and available on many platforms. This is only a start though. SQLite is very liberal on SQL syntax and lacks an intneral programming language like DBMS systems have. Still, if you want to start and learn with minimal overhead, SQLite is the way to go.
SQLite is nice and they have really nice documentation, however you should be aware that it is not a full featured SQL database like MySQL, Postgres or the commercial variants. SQLite's API relies on callbacks which is a fine model, but not all database APIs work that way. If you are familiar with Perl, then DBI is another nice way to explore SQL.
/Allan
"A Gentle Introduction to SQL" - You can even practice "live queries" right on this tutorial website.
http://sqlzoo.net/
I always recommend The Practical SQL Handbook for a good starting point for beginners - especially those who have seen SQL but never understood how to build up a query them selves or how they work.
All Celko's books are great.
Hernandez's Mere Mortals book is good.
Ken Henderson's books are also excellent.
Reading up a bit on relational algebra is a good way to understand the underlying concepts of relational databases.
Jeo Clecko's SQL for smarties is excellent.
I recommend the exercises at this site: sql-ex.ru
You can even get a certificate if you do the right.
Start with Ideone and try queries on line just with a web browser.
If you program using the .NET framework, then learning LINQ might be a good place to start. The LINQ "engine" will handle the back end communication with the database (or objects, or entities, or XML, etc.) for you. If you want to dig deeper, you can explore the SQL generated by the LINQ that you write.
If you already know a thing or two about web applications, then that would be a good place to start. Nearly every serious webapp uses an SQL database as its backend.
The folks at Head First have come out with a book. Going by how good their other books are, I'd recommend this one. Haven't read it yet though. (LINK)
You may want to consider starting with MySQL as it is widely documented and very easy to get started with. You can download the Community Edition and then add the GUI Tools and you'll both GUI and command line interfaces.
Read a book to start learning about SQL. I read Beginning SQL Queries from Apress not long ago, and found it clear and logically written for a beginner (I reviewed it for a colleague).
I learnt 90% of what I know about SQL from here. In 1997.
I think it still stands up.
Hey although not complete it's great to get hands on with SQLite as mentioned above, Google 'Learn SQL the hard way' and there is an online book which you can work through which uses SQLite.
Google is great for downloading pdf's for free 'Cough Cough' but try http://www.sqlfiddle.com/
It's an online platform which is free! No log in required just go to their page, create your database in whichever language you want (That's the best bit I choose T-SQL as I'm learning that), and then you can query it as much as you like. I'm learning with a pdf file which has opensource SQL files you can download to follow along, and SQLFiddle has been great to learn vendor specific SQL.