I'm new to NHibernate and I'm testing it right now as I can't find any simple solution in saving master/detail records in a single transaction using DataSet.

I have already built the models and able to read and update record from DB. However, the problem comes up when I try to make it work with the databinding. I don't know how to databind my model to the web UI. For display only, it's fine to set the DataSource to my model directly in source.

Me.GridView1.DataSource = objName
Me.GridView1.DataBind()

However, if I want to have those update ability, it seems that it's better to create an ObjectDataSource and databind to it. However, how can my ObjectDataSource link up with my model? Please let me know if there's any tutorial available.

I found that some people will suggest making a facade? However, I've no idea what's it. I'm not strong in OO design. So, please give me a path to achieve my goal. Thanks!

Hi there,
I have the same problem. I want to leverage the new ObjectDataSource functionality but I can't find a simple way to query my objects to a table. Right now I'm building the table manually by adding DataColumns for each property in my object and adding each row from the IList into the DataTable. It's really tedious. Is there another way?
Some kind of a IList.ToTable() method would be really lovely.

Cheers!

I'm not currently working with .NET 2.0 but as far as i know you should be able to bind any collection derived from IList to an ObjectDataSource. If you want to add / delete rows in a datagrid then the collection bound to the grid has to implement the interface IBindingList. But you can also emulate this with an Add and Delete button.

Regards
Klaus

My (unpopular) advice is to avoid the ObjectDataSource, SqlDataSource and so on controls. THese RAD controls are designed to quickly build applications that cause a brittle dependency between presentation layer and model (read: facade, service, etc) layers.
The amount of time you spend trying to bend these ViewState monsters into submission would be better spent building a rich domain model.

Any collection that implements IEnumerable (all of them...) can be bound to a GridView or Repeater or whatever. .NET uses reflection to get the property values during .DataBind() and binds them to the control. You don't have to convert a collection of POCO objects (read:classes) to a DataSet or DataTable...the properties (not fields) can be bound to whatever controls you have placed in your DataSource controls (like a DataGrid, GridView, Repeater, whatever). To post values back ('2-way databinding') is not a big deal to enumerate over teh control and either iteratively send values to the lower layer (such as a Presenter or a Controller) or have the event delegated to the lower layer and allow the Presenter to grab the values.
You see, you shouldn't have business logic in your presentation layer so try to push all that logic into the lower layers.
Read Martin Fowler's Patterns of Enterprise Application Architecture or Jimmy Nilsson's Applying Domain Driven DEsign book to get ideas on how to layer your application. This will answer questions like 'what is a facade' and (hopefully) steer you away from the drag-and-drop microsoft development methodology. RAD development is quick, but not very flexible, scalable, or maintainable (unless you have a big team and lots of money). The idea is to reduce duplicating code and reduce dependencies in your app that will cause changes to bubble up the application breaking things along the way.
MIKE

mnichols wrote:

But on the other hand it's simply boaring to write the code for binding my data to the controls. If you don't use the RAD features you have to write an Bind() and Unbind() method which transfers the data to the controls and vice versa. For Grids you have to write additional code which binds the data to the columns (or do you always take the property names as column header). Even if you use an generic way you always reimplement a feature which the framework provides for you. I used both approaches in my projects and the only advantage of not to use ObjectDataSource and so on for me is that i can decide myself when the user input is transfered to my data objects.

Regards
Klaus

Sure! It depends on the project you are working on. The main thing to consider for me, tho, is how high up to the view I can test. If I avoid DataBinding and push the data into the controls from the lower layer (such as a Presenter), I can actually test as close to the view as possible.
Keeping biz decisions (if they are that) such as formats for property names and so on in teh view controls or *DataSource controls keeps me from being able to change those formats and so on in code where I can reduce duplication effort.
I know there are lots of ways to do this, but it seems to me that when you bind using these RAD controls you have lost testability and flexibility for change. If you aren't unit testing that far up the layer scheme perhaps it won't matter...

Something like this:


Basicly, this is a simple wrapper around NHibernate or a wrapper around your DataLayer that is itself a wrapper around NHibernate. You mark it with attributes that identify it as a DataObject and idenitify the purpose of the individual methods, as that helps the GUI tools pick the right objects and methods for you. Likewise, the naming convention of FooInsert is preferred by some over InsertFoo because of the way the GUI tools will sort the methods.

The ObjectDataSource then looks at all the parameters it has and tries to find the right method signature that has all the right parameters. Be sure to specify the DataKeyName on all your GridViews and such.

It's not without pain and it's definitely time consuming. Is the tradeoff worth it? I haven't completely decided myself. For read-only stuff, I'd definitely say just stick with binding directly to strongly-type collections returned directly from your DataLayer. But once you do get it working, it gets easier and easier the farther you go with it.

Perhaps most importantly, any other ASP.NET developer can work on your UI without having to know NHibernate first. Seeing how bloody hard it is to find anyone who already knows NHibernate on short notice, that's a very good thing.

That's a valid concern, but still a tradeoff. The lower you do your formating, the harder it is to distribute that work to other people. You limit your available labor pool to people who are qualified to work on the lower levels of your code.

For example. what if the marketing guys demand that you need a version in some obscure eastern european dialect in 3 months? They don't use MM/dd/yyyy! They use dd-MMM-MM-yyyy for some screwy reason. With the formatting in the code, you either have to build internationalization concerns into the deepst foundation in your code or you have to fork a translated version of the code.

With all the formatting and display done in ASPX with DataBinding, you can outsource the internationalization to a firm that specializes in translating ASPX (or at least hire a junior programmer who knows vanilla ASP.NET stuff).