As someone who uses the DevX grid quite a bit in a VB.Net Webforms app with static/Shared methods to encapsulate various data access logic, another approach would be to skip creating a ObjectDataSource
in the ASPX and instead set up the grid's DataSourceID
in the code-behind's Page_Load. I founded this much more manageable and predictable.
Here's the idea:
Private Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load
Using eFContext As New ApplicationEntities()
Dim requestedTransactionId As Guid = GetAndCheckQueryStringValueGuid("TransactionId")
Dim requestedTransaction As Transaction = Transaction.GetAndConfirm(eFContext, requestedTransactionId)
Dim requestedCustomers As IQueryable(Of Object) =
Customer.GetCustomersForCustomersGrid(eFContext, requestedTransaction)
CustomersGridView.DataSource = requestedCustomers
CustomersGridView.DataBind()
End Sub
I also create a new EF context for each request in Page_Load - I've not found the performance associated with this to be an issue and it makes hunting down problems 10x easier. You may want to consider this, at least to get started. I've seen others in the past suggest putting your context into Session state and fetching it from there when needed, but that feels like it could cause all sorts of hard-to-track-down badness so I've never been bold enough to try and make that work.
As a side note for if you follow my suggestion: if your initial load of the ASPxGridView works but you get errors as you move from page to page, sort columns, etc. then you may need to use some .Includes
for associated entities that display in your grid.