I am working on a project that connects a Visual C# form to a MS SQL Server 2000 database with standard CRUD functionality. My client is requiring me to use a NHibernate layer to handle the interchange as they may want to use it on an Oracle database instead. The missing puzzle piece for me is data binding the form controls to NHibernate rather than to the database. Is there an easy and time-effficient way to bind the objects handled by NHibernate to the data aware controls? Can I populate a DataGridView control from the NHibernate layer? Your help is greatly appreciated.

because you mentioned the DataGridView in your posting i assume you are using .NET 2.0. You can bind any collection derived from IList to a DataGridView. If you want to be able to add new lines the collection must also be derived from IBindingList. To bind an instance of your persistent object to the controls of a form (e.g Textbox, Checkbox etc) you can use the ObjectDataSource to to this visually in the designer.

Regards
Klaus

Klaus,

Thank you for your encouragement and help.

There are some interesting architectural questions posed by this question and ones that I am also working to solve myself at the moment

Reading some NHibernate papers the recommendations seems to be to isolate NHibernate in a Data Access Layer and to try not to expose NHibernate internals to the business lgic and GUI layers.

Trying to comply with the abvoe, my Data Access Layer is accessed via a factory which provides DAO objects for each core business entity to be persisted. Collections are provided (Generics), one for each of the core business objects, these collections implement BindingList so they can be directly bound to user controls. The idea is that these collections may also be extended if necesary to provide basic sorting and filtering operations etc as required which I believe are not available as standard with the BindingList. Currently my collections contain the business objects that are to be persisted but it could also be at a later date I could decide that the buainess objets are in fact courser grained objects than those that are persisted via NHibernate. However this is not the case at the moment

With this approach I am hoping to acheive a clear layering within the applicaiton e.g seperate, GUI, Business Lgic and Data Access layers.

I have just started on this approach so I am interested in feedback from anyone who has already travelled this route and can provide some recommendations in architecting solutions uisng NHiberante with C# GUI's.

TIA

Steve

Hi Steve,

me and my team are just finishing an application which uses a similar approach.

We had the requirement that the application should work on a 56k modem line with acceptable performance. So we decided to place all business logic which uses heavy data access on a application server and called it "Smart Client" :-). We placed the data access layer in a "Service" dll and some common logic in a "Common" dll which are used both from the Gui and the Server.

Our data access layer returns pure POCO's, the business logic is separated into own classes. As the database changed often this helped us to implement a generative approach (We use MyGeneration to generate our mapping files and POCO's). On the other side we are able to use the business logic from other applications (which was also a requirement). We provide a Web Service interface into our business logic. The Web Services use only string parameters to guarantee the highest compatibility with non .NET systems. These are converted from / to our POCO's in the service methods.

Regards
Klaus

I'm using more or less this way to my development.

On gridview's I use the objectdatasource to make paging.

In the dropdownlist I bind a collection normally, or in some cases I use methods to generate the collection of listitens that need to have textfields with more than one field of an entity object.

Out of theses, everything is as I used to work.