Linq-to-SQL/EF or NHibernate.

Question

Hi,

Accornding to limited reading i have done about NHibernate from internet source, gives me a feel that NHibernate is good for WinForms apps,  NHibernate is not suitable for ASP.NET applications because of the ASP.NET stateless behaviour.

What are other's take on this?  anyone who have used it with ASP.NET , please let us know about its limitations with respect to its usage in ASP.NET

Regards

P.S In one of the forums i read "EF does not support POCO".  What is POCO? and its meaning?

Answer 1

To answer the POCO question, I have heard three definitions:

Plain Old Custom Objects
Plain Old CLR Objects
Plain Old C# Objects
(Though I disagree with the last one because you can define these with VB as well.)

Regarding "EF does not support POCO" ... there has been some work in this area:

http://www.pnpguidance.net/post/DownloadEFPOCOAdapterUpdateEntityFramework.aspx

http://blogs.msdn.com/jkowalski/archive/2008/09/25/ef-poco-adapter-updated-v1-03.aspx

I can't comment on NHibernate ... I have not used it.

Hope this helps.

---

www.insteptech.com
We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!

Answer 2

Hi

I've used both extensively..

Nhibernate is pretty easy to use in both asp.net and WCF scenario's, as long as you keep in mind that your data access can not use the 'default' approach of having you items constantly connected. 

What a 'normal' approach would be is to load items from the db and store it into sessionstate..
which means serialization, and disconnected data access (think the briefcase model)

So you basically have to think hard about modelling your classes as you don't have any of the fancy options (lazy loading etc)
I would consider your data access itself as a service (even if it's in the same layer) with your service boundary being the point on where you lose your db connection and all the fun associated with it.

Personnally, Nhibernate is a much more mature model to be dealing with, and it would be my weapon of choice for any project.

KR

---

Please close the thread if your question is answered, and don't forget to rate the best responses!

Answer 3

Hi

So you say my approach should be "Storing data into session"... well .. I visualize that with this approach,  i would be eating up my server's memory. (assume when no of users are more, it would hit performance greately)

Also can anyone recommend me a good URL which shows a cleaner way to install and setup NHibernate for ASP.NET.  A URL I visited(forgot the url link) was much confusing for me
with too many changes in web.config involvinig httpHandlers.

Regards
 

Answer 4

Thanks Deborahk for the reply,

All i could make out is that POCO is related to some concerns with UnitTesting, but still I lack understanding of the problem senario and could not get a clear picture how those adaptors helps to resolve the problem.  May be if you can describe with an example.

Regards

Answer 5

Hi

what you're saying isn't really correct..
asp.net session state comes in multiple flavors:
- in process (in memory)
- state server (in memory on another server)
- sql state (your session state is serialized and put into a database)

Choosing the latter has very little impact on performance, plus even when you choose in process session state, a session times out after 20 minutes of non activity (by default)

Note that sessionstate is the default way most people develop in asp.net
Of course you can go the other way and contact your database at every request, it's a valid option.

Something I forgot in my initial answer,
take a look at sharp architecture, an open source project which has some more info on using NHibernate in a web context (session per request, etc)

KR

Frederik

---

Please close the thread if your question is answered, and don't forget to rate the best responses!

Answer 6

Hi

poco means having a class like

class Order{
public Customer Customer {get;set;}
}

this is a plain code object, no fancy stuff...

with entity framework (one of the previous versions at least) you had something similar to (it's been a while):

class Order{
private int _customerId;
public EntityRef<Customer>  Customer {get ;set;}
}

EntityRef being something internal to the Entity Framework.
Basically having this means that your code is now explicitly bound to EF, and anyone wanting to use is needs to have those binaries as well => leaky abstraction.

Furthermore, in testing scenario's this becomes a bit painful, as the EntityRef requires a database connection to function correctly.
In the end, EF doesn't really support disconnected data access (at least not when I last reviewed it).

KR

Frederik

---

Please close the thread if your question is answered, and don't forget to rate the best responses!

Answer 7

No POCO has nothing to do with unit testing.

If you follow object-oriented principles in your code, you are doing POCO now: Customers, Orders, Invoices, etc.

The Adapters is only to provide a way for EF to work with your own POCO classes. You don't need this if you plan to just use POCO.

I have examples of applications done without EF or NHibernate that use plain old business objects if you want an example.

---

www.insteptech.com
We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!

Answer 8

Thanks Deborahk, Frederik for the replies.

If there is any step-by-step tutorial of NHibernate with ASP.NET do let me know.

Regards
JIGNESH.

Answer 9

Worth having a look at http://www.rmfusion.com/microsoft_net/linq/linq_to_ado_net.htm and http://www.rmfusion.com/open_source/nhibernate/nhibernate_net_introduction.htm which have good examples comparing using LINQ to ADO.NET vs NHibernate.NET for data manipulation. Shows the same functionality (application) implemented in both LINQ to ADO.NET and NHibernate.NET.

Answer 10

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

Here is another good walk through of NHibernate.Net