I wouldn't say your idea breaks the intended use of CSLA. CSLA defines a means to get your data back and forth, but it's certainly not the only means. And for dynamic situations like this - well, there isn't a "good fit" style within the framework that I know of.
If you're uncomfortable with your XML solution, I can offer an alternative, but I don't know whether you can get it done with the tools you have. I don't have any DevExpress experience - our tool of choice has been Infragistics - but the tool vendors are all remarkably similar these days, so this should hopefully translate.
(FWIW, I don't see your XML solution as a bad one. I probably wouldn't do it that way, but that's largely because I think the overhead of translating all the data into XML - even if you do it on the database - is a bit much for a data-transport medium. Also, my users have an annoying tendency to rather quickly depart from a solution, and in this case my experience has been that this read-only list will become not-so-read-only sooner rather than later...)
Infragistics has a component - they call it the UltraDataSource - that is essentially designed to make it easier for data-binding-aware controls to work with "ordinary objects" - i.e. classes that don't have all the built-in data-binding support that CSLA offers. All it really is is a design-time component that implements all the data-binding interfaces, and gives you hooks to set the record structure and load/update your object data. Like I said, I don't know whether the DevExpress suite has an equivalent, but I would be surprised if they don't. Anyway, what you could do is to retrieve your object data as you normally would - without doing the XML transformation - and from there build the structure in your data-source control. Your grid then binds to that control. Under this scenario, you can use a ReadOnly-based object to get your data, instead of a Command object and some XML translation somewhere. You're still not taking advantage of the data-binding that CSLA objects give you, but given your situation, you probably won't be able to anyway.
I can't say for certain that my idea would be any faster than doing the XML translation and feeding it to the grid, but I expect it would be, if for no other reason than I'm removing the XML transformation step. The grid can't bind directly to XML, so what it's doing is translating/copying the XML into a temporary bindable object and then binding to that - which is essentially what you'd be doing in your code. That's why I called the XML a data-transport medium earlier. But your users could be a little happier with this method over the direct XML feed. The downside to the XML feed is that unless you provide schema information with your XML data (assuming you can), the translation routines usually turn everything into strings. Coding it yourself gives you the opportunity to provide the proper data types, giving your users a better experience with sorting/filtering.
HTH
- Scott
Copyright (c) Marimer LLC