Apart from the fact that it’s open source and mature, what are the differentiating factors that separate nhibernate from rest of the .net ORM frameworks like Subsonic, ADO.NET Entity Framework etc?
Better put, why should I choose nhibernate over other .net entity frameworks?
The biggest reason is probably that nHibernate supports persistence ignorance; your entities can be plain old CLR objects (no base class). It also supports unit of work (updates are automatically tracked and batched) which Subsonic does not support. Also, Entity framework does not support implicit lazy loading (when you want to access Order.OrerItems, you have call Order.OrerItems.Load()). It forces you to think about lazy loading, but also pollutes your buisness logic with infrastructure concerns.
Related
I'm familiar with the EF and it looks pretty cool. As far as I can see, it is basically a LINQ to SQL with extra functions (like caching, automatic connection handling and so on). However, in my opinion EF is useful for those applications that directly comminicate with the model data (~persistence).
In case of writing a RESTful web service, we are reading and writing objects (for example) in JSON format. The application calls the web service with some data and it returns data back.
That's why I'm actually thinking on not using EF because it looks like an overkill for me. Since I'm not planning to expose the actual model, I would use DTOs instead (both as input and output of a web service call). This means that I have to do the mapping to the underlying model anyway so the EF would be used as a LINQ to SQL wrapper.
Is there anything I'm missing? Is there any feature that would be useful while writing a RESTful web service? is there any benefit from using EF instead of LINQ to SQL?
So the logic here is that you aren't exposing your entities past the data layer, so EF is pointless.
I never expose my EF Entities pass the business layer, just one layer down from the data layer. I always project them to ViewModels and Models which are just POCOs. I've seen this in lots of projects.
Rarely do I actually use the entity change tracking features. By the time a GET/POST has occurred it doesn't make sense to requery the entities on the POST just so you can update them via change tracking. Instead a direct update makes more sense and avoids an unnecessary roundtrip to the database.
My point being is in what I've seen it most commonly used, the EF models are not exposed past more than one layer in most cases. This ensures View/UI layers don't accidentally modify EF state or cause lazy loading(which is usually disabled).
However I still get to leverage the great EF/DB mapping layer and EF LINQ queries, which is by far the greatest features of EF.
Most alternatives such as Dapper are just that, a framework for executing queries.
So I wouldn't fallback to just doing ADO.NET or an older query technology just because you aren't using all the features of EF. You should still use a modern query framework such as EF or Dapper, simply because you are still executing queries. Just because you aren't exposing the entities doesn't change that.
I'm working on an n-Tier Domain Driven Design project that uses Entity Framework 4 DB-First and Automapper to produce POCO's in the Domain's namespace.
To clarify: The EF project returns entities in the MyProject.Repositories.EF.Entities namespace and I use Automapper to turn them into entities in the MyProject.Domain.Entities namespace.
Now, I can't quite make out if when I map between the EF and Domain entities, if all the collection properties are enumerated, i.e. if all the related data is also retrieved from the DB when they are mapped, or if they are still only lazy loaded when I actually enumerate them in code.
I am concerned about the obvious performance implications.
Turns out the answer is no. As long as you map between two IEnumerables, the actual enumeration will only take place when you perform a foreach, ToList(), etc. If you don't perform actions on IEnumerable properties of these objects, the enumeration will never happen and the related data will not be retrieved.
Long story short - this is not a concern of AutoMapper, but of how you use your ORM. AutoMapper merely removes code you would have already written, so if you would have written lousy performing code against your ORM, AutoMapper will happily oblige.
People were abusing ORMs before AutoMapper, while using AutoMapper, and after using AutoMapper. Lazy loading is a powerful tool when used correctly, but still can be abused. Using lazy loading does not preclude the developer from understanding what is actually happening underneath the covers.
So use AutoMapper, but take care with your fetching, just as you should be doing had you NOT used AutoMapper.
I can see in the manager extensions, that exists EF 4.x dbcontext and EF 4.x POCO. Both of them generate entities for persistence ignorant.
What are the difference between them?
What are the difference between 4.x and 5.x? which is the new features of the 5.x version?
Is it possible to use only one exchange entities for all the ways to access to the database? I would like to use an interface to use different ways to access to the database. EF 4, EF 5 and others than not necessary it would be EF. I would like to program once and use it in many scenarios.
DbContext is your gateway to all the entities in your model. For instance, if your context was called con, you might call con.Orders() to get to your Order objects. POCOs (plain old CLR objects) generated with Entity Framework do not extend classes from the Entity Framework. POCOs with Entity Framework are more advanced, so I recommend you not use them when getting started. One of the new features with EF 5 is replacement of DbContext with ObjectContext. OK, not replacement, because you can still use the DbContext. But Microsoft wants ObjectContext to be the new simpler way to access all your entities instead of DbContext. ObjectContext is much easier to work with in most cases.
I am currently working on a software project which uses SQL Server database to store data. Since there are some plans to move away from SQL Server to Oracle, one of the requirements is to build pluggable database layer.
So my question is what is the best way to do it?
You have lots of choices. One option is to go with one of the various Object Relational Mapper (ORM) frameworks out there. NHibernate is a popular one, but Microsoft's Entity Framework (in v4) is a reasonable possibility as well, and it integrates better with Linq, if that's the sort of thing you're interested in.
A second option (not necessarily exclusive of the above) is to implement something like the Repository pattern, and run all database access through a repository layer. Some folks see the ORM frameworks as a replacement for the Repository pattern; other see a repository layer adding value on top of the ORM framework. The real value that a repository gives you is the ability to swap out ORM layers. Only you know whether that's a reasonable likelihood, and even if it is, it may be more work to implement the additional repository level than to just re-bind everything to the new ORM.
I suggest using Entity Framework, quite easier than NHibernate and being matured very fast. For oracle support in EF, you'll need the oracle provider.
Along with using Entity framework, I suggest using a pattern such as Repository Pattern. This way, you can use Dependency Injection to change the implementation of your choice. Your application becomes independent of database or the ORM itself. So you could also use NHibernate if you wish.
I would recommend using NHibernate for your data layer. With it, you can easily swap out the configuration to work with almost any database driver you want.
NHibernate has good support for both MsSQL and Oracle.
You can write all your queries in Hibernates query language (HQL) which will be dialect agnostic. Another option is to use the linq provider in NHibernate 3 to get strongly typed data access.
As some other have mentioned, i would also recommend using the repository pattern and inject a Unit of Work or a SessionFactory.
Edit: Oracle now has released a beta of their Entity Framework provider: http://thedatafarm.com/blog/data-access/oracle-entity-framework-beta-released-today/
1: http://nhforge.org/Default.aspx## Heading ##
If you want to go ORM way, you can use NHibernate as alexn suggested, or Telerik's OpenAccess ORM. There is also EF provider for oracle and other DBMSes, but they are not free.
If you want to build your whole DAL from scratch, than go with Repository pattern. Create an interface for repository and create each repository provider for each db. Here's a discussion about.
I've been programming in C# 2.0 WinForms for a while now. I'm starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I've only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I'm all for it.
I followed the tutorials on the www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.
My questions are:
Is one method better than the other?
What are the benefits of one over the other?
Is it possible to see the SQL that is generate when using either of the methods?
Since I'm new to the ASP world, are web developers leaning on one side?
2: LINQ-to-SQL has the benefits of being simple (but still well engineered) - but the downside of being simple ;-p
LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
Entity Framework supports more abstraction between the data (storage) model and the object model - LINQ-to-SQL is literal table/column => class/property[|field]
LINQ-to-SQL is actually more "complete" in the stuff it does do:
EF doesn't support UDFs
EF doesn't support things like sub-expression invoke (for custom expression trees)
EF doesn't support some "obvious" methods like Single()
EF doesn't have some of the TSQL optimisations that LINQ-to-SQL uses
Basically EF at the moment is a bit more of a "v1" (or even "v0.9") product. However (and importantly) - EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.
At the moment, I'm very happy to use LINQ-to-SQL, but EF is on the long term... so I'm using repository etc to hide some of the gory implementation details - a bit of a leaky repository, but pragmatic.
3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well - or I have one that writes to the trace.asax. With EF, ToTraceString.
4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I'm wondering how much this will change when EF is next released in .NET 4.0...
Use the one that feels best for you, your team and your project. It doesn't really matter how you access the data, as long as you access it.
You could use plain old ADO.NET if you want.