Creating Database class Library using NHibernate - c#-4.0

Question

I am writing an Class Library as DataModel. DataModel capable of handling all the Database related task. I am using NHibernate and Fluent NHibernate for the same.
Now the question arises are as follows :
Should we expose the Entity (POCO Class).
Is it good to have a Entity with internal protected property and property exposed as a interface.
Entity created for mapping can be a Model for WPF MVVM.
Or should we directly bind entity ?.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Is it right to throw Exception occurring in an API or should I return null?.
Is it good keep logging in the Library ?.

Answer 1

Should we expose the Entity (POCO Class).
Yes, Creating wrapper class makes more effort.
Is it good to have a Entity with internal protected property and property exposed as a interface.
Yes, Setter and non-exposed properties are control.
Entity created for mapping can be a Model for WPF MVVM.
For primitive type can be, but reference can be exposed by interface.
Or should we directly bind entity ?.
If Model is created rather directly use of POCO object. It is much more flexible for refresh cases. User can not change property of POCO object if cancel operation is there.
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
IEnumerable is used to exposed collection by interface.
Is it right to throw Exception occurring in an API or should I return null?.
Exception is much more better to make know to user about error. but wrap the exception in user readable rather returning NHibernate exception.
Is it good keep logging in the Library
Logging is very good feature to know about issue.

Answer 2

Should we expose the Entity (POCO Class).
yes, otherwise whats the use of the entities when nobody uses
Is it good to have a Entity with internal protected property and property exposed as a interface.
It depends! internal protected properties are no problem when using an ORM but i prefere to reduce internal stuff to a minimum because i like objects maintaining their own state. interfaces are fine
Entity created for mapping can be a Model for WPF MVVM.
of course. No need to duplicate them another time. That's what persistence ignorance is for
Or should we directly bind entity ?
More ofthen than not, the UI requirements are very different than persistence/businessrules so there will be specialised ViewModels for UseCases/Views. However simple Dataholders like Order class thrown into Lists can be bound directly (e.g. using a DatabindingFactory to make them implement INPC)
There is no control if Library returns a List of entity as API return. So anybody can do add or delete in list. How should I keep control on it. Should I create proxy derived from IList which will keep track of it.
Lists are just in memory container. The user still has to go through the API to Save/Update state.
Is it right to throw Exception occurring in an API or should I return null
if collections are returned then empty collections are far better than null.
Exceptions however should bubble up preferably wrapped in own handable Exceptions. Implement NHibernate.Exceptions.ISQLExceptionConverter (e.g. like NHibernate.Test.ExceptionsTest.MSSQLExceptionConverterExample) and configure it with e.g.
config.DataBaseIntegration(db => db.ExceptionConverter<MyExceptionConverter>())
Is it good keep logging in the Library
absolutly. Logging enables debugging deployed applications. (Fluent)NHibernate already has lot's of logging built in use it if possible.