Since I have given up on using the entity framework 4 as my ORM (getting it to work with MySQL and mapping table/field names like this_table/this_field to object naming like ThisTable/ThisField is POCO) I am now looking at NHibernate as it seems the the next big well know ORM for C# that probably with not die off any time soon. I am trying to lookup some tutorials and a lot of them in the configuration section have 2-2 in it and was wondering if those configuration would work with NHibernate 3? I am just curious if the 2-2 refers to the version of NHibernate or something different.
I assume you're referring to this:
urn:nhibernate-mapping-2.2
as often seen seen in the mappings. That's not the version of NHibernate, it's the version of the XML schema. The previous stable version of NHibernate was 2.1.2, and as far as I can tell there hasn't yet been a 2.2 (although in the future there might yet be one -- as I understand it, NH 3 targets .NET 3.5 and I'd imagine there are a lot of people who can't upgrade yet).
Related
I'm working on a project using entity framework 6. At the start of the project I was a beginner with EF and choose to build with EF model first.
Now the model is quite big and I’m thinking about performance and ease to change the model without dropping the databases every time.
I thinking about switching to code first.
Given that model first has already generated all the classes I need and context, I don't think it's that difficult to switch to code first.
Nevertheless I would like to know what would be the best way to do that and if there will be real advantage in term of performance and ease of model modification.
Thanks for your help,
EF 6.1 tooling now allows creating a Code First model from the database. Here is a short video and a walkthrough showing the functionality. You can download the latest EF tooling from the download center.
The code created by EDMX is not same as Fluent API although it is closed to Data Annotations.
If you would like to work with Fluent API, you can use Entity Framework Power Tools Beta 4 to generate to Fluent API from Database.
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
We currently have a solution that was completely written by hand in ASP.NET and MVC.
There are a lot of ugly hacks and workarounds in the DAL currently and rather than expand on these hacks, I've managed to convince the suits that we need to migrate to an ORM of some sort.
With Entity Framework experience in the team, we've decided to go with the Entity Framework, however, I have a migration question for anyone who may have had an experience with this.
Would there be any performance issues if we were to migrate Entity-by-Entity until everything was migrated to EF? What possible roadblocks (other than the obvious of having to rewrite most of the BL) could we face? Should it literally be done Entity-by-Entity (in terms of, creating the models) or would there be issues creating the entity model and just changing the BL bit-by-bit.
I can't seem to find any documentation on the subject.. MSDN seems to just say "Yay Entity Framework is good, so migrating to it is good.".
Any advice would be appreciated.
PS: I did read this: Migrating from 'native' OODBMS to ORM (Entity Framework / SQL Server)
However as we've decided to go with EF instead of NHibernate, it didn't prove very useful.
It's good question and i have a answer from my prospective. It's about 'Yay Entity Framework is good, so migrating to it is good'
Now our team is working over big (very big) HR SaaS solution. From the beginning we decided to use:
EF 4.1
MySQL (that was requirement from client)
.NET MVC 3
Then time passed (near 3 weeks) we noticed next about EF: using Model first is not applicable and useful in our system in case of hard to support system in future when we need, for example, change a little bit db structure or make new relations between tables.
In this case we moved to EF Code First (with one generic repository for all db requests). That was the risk cause it's so new technology and there was no best practices or use cases on big solutions. As result we recived a lot of other headache:
ORM made a lot of db requests (cause of a lot of relations between tables). Fixed by .Include()
Dynamic Proxy for POCO objects - made a lot of troubles, cause in code first entities from db came not like requested entity type - like dynamic proxy type. So when we tried to serialize them and put to Memcached on deserialization we get the error that this entity no more available in current context. Fixed like this: http://msdn.microsoft.com/en-us/library/dd456853.aspx and this: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
Stupid bag with Membership that sent a lot of unbelievable requests. Fixed by reviewing our work with Membership
Also we tried NHibernate to just compare performance. NHiberanate has the same :)
General info that you should know about EF:
If you want to attache 3rd part caching be ready for workaround. NHibernate have a native integration of this
There is no big different between EF and Nh performance, but Nh have a lot of hand work with mapping
Hope i answer to your questing and info is relevant for you.
ps> sorry for my English :)
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.
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.