Hi!
Is anyone using NHibernate with ObejctDataSource and GridView and the builtin update functionality?

It works ok but I still have to copy values from the InputParameters to a NHibernate object (by reflection) in the ObjectDataSource.Updating event. Has anyone been able to get rid of that step?

thanks

Hi Dala, I have the same problem, I can't call a method with a Type parameter, so then by reflection make the query....
There is a <parameter> properties in ObjectDataSource but it doesn't support this kind of paramater type (class Type)

anyone help us?

Hi,

You may have already figured it out by now, but you can use Domain objects directly instead of having to use seperate parameters:

You need to set the DataObjectTypeName property of the ObjectDataSource to the Domain object type.

Once you do this you do not need to explicitly define individual parameters or
use reflection.

Let me know if you need more detail.

Yes, please, please, please add some detail :)

I must be missing something to the ObjectDataSource

If you did this
1. Create a ObjectDataSource where the Select calls: IList GetAllCustomers()
2. And the Update calls: UpdateCustomer(Custromer c)
[Customer has public properties for all fields]
3. Create a GridView that uses the ObjectDataSource but only displays a subset of the fields (ex: FirstName and City)
4. Use the "Edit" command and then the "Update" command.

This will happen
When the "Update" calls UpdateCustomer(Customer c), the object passed in will only have FirstName and City values set, the others will be null!

Unfortunately, this aparently is how it is supposed to work.

Work around approaches that I have found
- Include all of the columns in the GridView.
- In the ObjectCreating and ObjectDisposing events, get/save the objects to the cache .
- Create overloaded methods for UpdateCustomer with all combinations of parameters (this can be a pain to maintain).

Any suggestions on how to know which row was edited and to end up with a complete updated object without doing a bunch of work?

I am setting DataKeyNames in the GridView and DataObjectTypeName in the ObjectDataSource.

Note: I can get it to work against the Domain object but only if all of the properties (a.k.a. fields or columns) are included in the GridView and are visible.

Thanks,
Steve

Technically we haven't gotten this far (i.e. we haven't created an ASP 2.0 prototype using NHibernate yet), but our design team is thinking through these issues at this point. One approach I'm suggesting is to create base classes called ObjectView and ObjectViewRow.

The ObjectView would have a Rows property, a collection of ObjectViewRow instances. Each ObjectViewRow would be an IList of the displayed grid column values. To keep track of which ObjectViewRow item will bind to which entity property (In our case, a typical grid needs to display properties from 3-5 different entities per "row"), the ObjectView will also have an EntityTypes collection property and a ColumnDefinitions collection property. Privately it would keep the IList result of entity arrays from the NHibernate query.

The EntityTypes property would be a map (IDictionary) of the entity types, keyed by their alias in the HQL query, that are in each "row" returned by IQuery.List(). The ColumnDefinitions property would be of type ObjectViewColumnDefinitionList, where each ObjectViewColumnDefinition in that list would represent one column displayed in the grid. It would map a column alias to an entity alias and property name.

The grid would bind to ObjectView.Rows. After getting the query results from NHibernate as an IList of object[] containing the entities on each "object row view", it would populate its Rows property with the flattened view for the grid. Since it's an IList of ObjectViewRows, each grid row should display a column for each IList item in ObjectViewRow (which is just an IList of objects). The ObjectViewRow's indexer setter would use reflection to set the corresponding entity property. If you want to change which columns get displayed in the grid, you just add/change/remove an ObjectViewColumnDefinition to the ObjectView's ColumnDefinitions property. Unless you need to display a property from an entity not selected in the query, you don't need to change the query. In any case, you shouldn't need to change the code posting back the changes, since that can be generic, simply looping through the ObjectView's private IList of entities originally queried.

This sounds like a lot of work up front, but we're hoping to be able to create a generic layer to take an arbitrary HQL query returning entities, let the UI define which "columns" it wants displayed out of those entities, and then do the binding automatically from there. The ASP controls will see a simple, flattened list which they should happily bind to, and this flattened list will bind to the real entities based on the mapping defined by the UI. We're hoping this approach will also work with little or no modification for windows forms.

Are we going off the deep end here? Does something like this already exist (ObjectViews on SourceForge?), in which case we're wasting our time reinventing it? We don't have a lot of ASP experience at this point (mostly client/server), so is there anything in this proposed design that sticks out as a serious bad practice in the ASP world?

Oh yeah, if binding to an IList of IList doesn't work well, i.e. if our ObjectViewRow must expose strongly typed properties representing each grid column to display, we would settle for subclassing ObjectViewRow for each grid in order to do so, and hand-code those properties in the subclass in addition to adding ObjectViewColumnDefinition items to a generic ObjectView instance (or, decorate the strongly typed properties with some new attributes that define the mapping back to the underly entity alias & property name). These strongly typed properties in the subclass of ObjectViewRow could be generated fairly easily if need be, using a wizard plug-in in VS.NET. In any case, each of their setters would then call some protected base method in ObjectViewRow to forward the value to the underlying entity's property.

There actually IS a project called ObjectViews on sourceforge. Give it a try to see if it fits your needs.

http://sourceforge.net/projects/objectviews

Hector Cruz

Sewart,

Yes, what I am doing is putting all non-visible columns into DataKeyNames.

So if I have a Person class with
Id
FirstName
LastName
Address
RowVersion

and only want to display/edit FirstName, LastName, then my DataKeyNames holds:
Id, Address, RowVersion

Cheers,

Adam

A problem that I'm running into with regard to using NHibernate with ObjectDataSource and GridView in ASP.NET 2.0 is that I need to access a property that is contained in another property and I don't know if you can do this using GridView. i.e. I have something like the following. I have an Application class which represents a job application. Each job application has an applicant which is of type Person. Person contains a property named Name. So, I've got a class structure like the following.


I want to display Id, DateTime, and Name in the GridView. In order to do so, I'd need to set the DataField value to something like Applicant.Name rather than a simple name. Does anyone know if it's possible to do this?

Am I better off simply using ADO.NET for this?

I'm new to ASP.NET. I'm wondering if maybe there is a way using a "binding expression" to do it?

The "object view" infrastructure we've created (mentioned earlier in this thread) solves this problem, because everything you want to bind to is defined as an "object view column", and ends up as a property directly on the "view row". These properties are updatable, and if you create a new "view row" or reassign the entities that underlie the "view columns", the entities hook up to each other properly, according to how they are defined in the view as related to each other. We have a view factory that builds these relationships from HQL statements.

We already went through the trouble of building this infrastructure, but as far as I know, there isn't a simpler way to deal with it. Even if there is for ASP.NET 2.0 binding, there is still the problem that we want to specify the scalar values that will be bound to controls as part of the HQL statement itself, but we also want to have access to the entities that underlie them, if the user wants to drill down or otherwise operate on the underlying entity for a given displayed field. Our "object views" give us both, with a minimum of fuss.

Thanks for the info. I'll have to look into what you've done.

It's probably the case that I just don't know what I'm doing with ASP.NET yet, but, from what I've seen so far, I much prefer JavaServer Face's implementation if data binding. I used to think certain aspects of JSFs data binding weren't as easy as they should be and I hoped that things were better in Microsoft's implementation. However, that doesn't appear to be the case.

I don't like the way that Microsoft's stuff seems to be geared towards using ADO.NET and assumes that you're working with database result sets. IMHO, it should work easily out of the box with standard in memory collections.

Maybe they'll get it right in another two years, if/when they ever get LINQ out the door.

I can't believe that <%# %> expressions are only one-way bindings. JSF is two-way.

Yes, <%# Eval("Applicant.Name") %> in ASP.NET 2.0 and <%# DataBinder.Eval(Container.DataItem, "Applicant.Name") %> in ASP.NET 1.x.

Thanks. I tried that and it didn't work. Eval() evidently only works within certain contexts and it wouldn't work where I needed it to work.

Hi,

The Eval syntax shown by Martin really should work.

Try this as well:

'<%# ((Applicant)Container.DataItem).Name %>'


Note the above mechanism allows you to drill into your objects..

If your Name object had properties (say First, Middle, Last), you could go:

'<%# ((Applicant)Container.DataItem).Name.Middle %>'

to drill into the Name object and display the Middle property

Cheers,

Adam.