Translating between Business and Service Entities

Topics: CAB & Smart Client Software Factory
Aug 30, 2006 at 4:50 AM
originally posted by: crickard62

Does anyone have any idea on how to translate a business and service entities containing data that would ultimately just be bound to a grid?

I have a business object that can be bound to a grid because it implements the following interfaces:

abstract public class businessObj : IEnumerable, ICollection, IList, IComponent, IBindingList, ITypedList
{
}

I am having trouble getting my head around the fact that I am going to have pass references to the business objects via interfaces throughout my presenter and view classes. Is there a better way?
Aug 30, 2006 at 10:32 AM
originally posted by: askew

Service Entities are very lightweight proxies for your business classes.
They are simply for transport over XML; XML Serialized, not binary.
Once they arrive at your Smart Client, you translate them back into your business classes and viola, you're back on terra firma.

The reason interfaces are so heavily used is that they support a plug-in type system where discreet parts of the solution can be replaced without recompiling the whole solution. That's all.

As far as how to translate, that's just mapping data from field to field. You can find an EntityTranslator service is a part of the SCSF solution framework (which, imho, is the best way to use CAB).
Sep 2, 2006 at 9:31 AM
originally posted by: ChrisHolmes

"They are simply for transport over XML; XML Serialized, not binary. "

That's a pretty narrow definition of a service.

To answer the OP though: Why are you against passing your business objects around? If it implements the proper interfaces to allow it to be bound to a grid, then why not do that?
Sep 2, 2006 at 9:39 AM
originally posted by: bil_simser

One thing that puzzles me though is why would you design your business entity to be bindable to a grid? A grid is a UI thing and business objects really shouldn't care about that silly stuff. As mentioned, you can use a service object for passing things around (and leverage the translator service to map from your complex object graph to simple types). I would look at binding service objects to the grid and using the translator to map values into and out of it.
Sep 2, 2006 at 9:41 AM
originally posted by: crickard62

"To answer the OP though: Why are you against passing your business objects around? If it implements the proper interfaces to allow it to be bound to a grid, then why not do that?"

I guess I am not against it but I questioned the "correctness" of introducing a dependency to an external/3rd party interface if there was a better way to do what I needed.
Sep 2, 2006 at 9:51 AM
originally posted by: ChrisHolmes

If your form requires data in a bindable format (necessary for any datagrid/list type element) then you're going to have a dependency on an object from somewhere. Does it matter if it's a 3rd party object or one you create?

We had to ask ourselves this same question. We use LLBLGenPro as our O/R mapper for our data layer. One of the features of that tool is that it will provide you with multirow data in a generic "EntityCollection" list, capable of being bound to grid-like controls. So we ask ourselves, "Do we want to rely on this object to bind to our grids?" The alternative is that we write our own bindable objects and then map the EntityCollection contents to our object, or even map them to DataTable/DataSets. But either way, some object still has to be created and consumed by the view, then bound to the grid. That dependency is going to exist one way or another.
Sep 2, 2006 at 11:02 AM
originally posted by: crickard62

That's the same decision that needed to be made here only the O/R mapper is EntitySpaces. In any case, thanks to everyone for their feedback. It's made this decision a little easier to make.
Sep 2, 2006 at 4:54 PM
originally posted by: askew

"They are simply for transport over XML; XML Serialized, not binary. "

That's a pretty narrow definition of a service.

You are right. Not a very good sentence.
Sep 6, 2006 at 8:07 AM
originally posted by: repattern

I think you can pass anything around - DataSets for example:

- they're bindable all by themselves
- free foreign key constraints
- I can design DataSets quicker than I can type
- clicking is more fun than typing
- anyone who has the interface can get the typed version
- those who don't have the interface can still work with the object by means of the DataSet interface (ex. you only need one ReportViewer control (view) in your application to display any kind of data without having any translation at all)
Sep 8, 2006 at 10:13 AM
originally posted by: ChrisHolmes

If I were not using a 3rd party O/R mapper I certainly would make use of DataSets more frequently. In fact, in one particular case a query our O/R mapper generates returns a DataSet with a DataTable that we bind to a grid.

There's a myriad of ways to deal with data. How folks solve that problem depends on the tools at their disposal. In our case, we have an O/R mapper we really like that saves us a lot of coding on the DAL, so we use their objects for most stuff (sometimes wrapping their collections in custom objects so we can add methods that manipulate the data in very specific ways).