Changing field in object?

[Brett Romero]

I'd like to copy a object1 into object2 so object2 can be manipulated.
Object1 is coming form the middle layer into the UI layer. I'd like
to rename a field in Object2 from "somethingID" to just "ID" and do
this several times for a few middle layer objects. This will allow me
to create generic<> lists and reference the field ID against many
object2s that are similar to object1. The middle layer objects have ID
fields with different names. This keeps me from creating one generic<>
class that I can pass in these objects from the middle layer.

Having the ID field name consistent across these few objects allows me
to use the generic class for referenceing ID at anytime. I don't have
to use switches or multiple classes at the UI layer to fill certain
form components with values from the objects...for example.

Is copying this object1 to the UI specific object2 and then changing
the field name the way to go? I could setup a transform class.
Before object1 passes into the UI layer, I transform it.

Thanks,
Brett

[Randy A. Ynchausti]

Brett,

Having the ID field name consistent across these few objects allows me
to use the generic class for referenceing ID at anytime. I don't have
to use switches or multiple classes at the UI layer to fill certain
form components with values from the objects...for example.

I think I would implement a general purpose interface that your "few"
classes implement. Then you would not have to rename any fields, if the
interface provided all of the functionality you would putl in the generic
class. That way, anything that implemented the interface would work in your
UI layer.

Regards,

Randy

[Brett Romero]

Ideally, an interface would work here. However, people at the middle
layer would be distracted with what people at the UI layer want. Those
particular areas of the middle layer are already complete. So middle
layer people would have to go back, retro fit, test, work with the UI
people. It should be possible for the UI people to handle it all on
their own. The middle layer people aren't much concerned with the UI,
as the UI isn't much concerned with the middle layer...as it should be.
Middle layer is building to meet certain purposes, not certain UIs.

There are several types coming from the middle layer. I just need to
rename a field in each type to something common. Then I can type a
generic<> class to perform certain operations using the renamed field.

Thanks,
Brett

[Jon Skeet [C# MVP]]

Brett Romero <ac*****@cygen.com> wrote:

I'd like to copy a object1 into object2 so object2 can be manipulated.
Object1 is coming form the middle layer into the UI layer. I'd like
to rename a field in Object2 from "somethingID" to just "ID" and do
this several times for a few middle layer objects. This will allow me
to create generic<> lists and reference the field ID against many
object2s that are similar to object1. The middle layer objects have ID
fields with different names. This keeps me from creating one generic<>
class that I can pass in these objects from the middle layer.

Having the ID field name consistent across these few objects allows me
to use the generic class for referenceing ID at anytime. I don't have
to use switches or multiple classes at the UI layer to fill certain
form components with values from the objects...for example.

Is copying this object1 to the UI specific object2 and then changing
the field name the way to go? I could setup a transform class.
Before object1 passes into the UI layer, I transform it.

Changing the *fields* should have no impact on other classes, as the
fields should be private anyway. If you use an interface (as Mark
suggested) you can have an ID property which all of the similar classes
implement.

Using interfaces is the best way of ensuring the separation you talked
about in the other post. It means you should be able to test the UI
layer without even having any "real" middle layer classes, using
mocking to implement the middle layer.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Brett Romero]

But again, this gets into having middle layer people be distracted by
the needs of UI people. If the interface is created and two properties
(sorry for calling them fields above) are implemented at the middle
layer, such that somethingID is implemented as ID, it won't stop there.
The UI will keep wanting additional properties as more meta data type
things are needed. So the middle layer people have to keep
implementing these new interface methods/properties.

The UI needs to have complete ability to do these things without the
middle having any knowledge of what's going on. How about this:

The UI side has a generic<> class that is typed as one of the middle
layer class types (eventually several types are used). Inside the
generic is a switch that delcares a Type object and checks that in the
switch. Once the switch matches, the somethingID property value is
dropped into a SortedList<string, int> where it can then be bound to a
combobox. There is another similar method in this class that binds to
a text box. In addition, I clean up any values to be presentable UI
side. For example, adding spaces and making proper letter case
changes.

Brett

[Jon Skeet [C# MVP]]

Brett Romero wrote:

But again, this gets into having middle layer people be distracted by
the needs of UI people.
I don't see how. The middle layer people *should* care about what's
exposed, and should consider commonality. They're providing an
interface to another layer, and should care about that interface.
If the interface is created and two properties
(sorry for calling them fields above) are implemented at the middle
layer, such that somethingID is implemented as ID, it won't stop there.
The UI will keep wanting additional properties as more meta data type
things are needed. So the middle layer people have to keep
implementing these new interface methods/properties.
Surely they have to implement those new properties anyway though, don't
they? It's not much more work to put them in the interface as well as
the class, and it means that the implementation can change without the
UI layer needing to know, so long as they've coded to the interface
rather than to the implementation.
The UI needs to have complete ability to do these things without the
middle having any knowledge of what's going on.
The middle layer always needs to know what it's providing - after all,
it's the layer providing it! It shouldn't need to know the order in
which the members are used (unless that's part of the interface
contract, which is likely to be due to a middle layer concern rather
than a UI concern) but it absolutely must care about what it exposes.
How about this:

The UI side has a generic<> class that is typed as one of the middle
layer class types (eventually several types are used). Inside the
generic is a switch that delcares a Type object and checks that in the
switch. Once the switch matches, the somethingID property value is
dropped into a SortedList<string, int> where it can then be bound to a
combobox. There is another similar method in this class that binds to
a text box. In addition, I clean up any values to be presentable UI
side. For example, adding spaces and making proper letter case
changes.

Anything involving switching on types is begging for polymorphism to be
applied if at all possible, IMO.

Jon

[Brett Romero]

>Anything involving switching on types is begging for polymorphism to be
applied if at all possible, IMO.

Exactly but how can it be applied in this case?

Thanks,
Brett

[Jon Skeet [C# MVP]]

Brett Romero wrote:

Anything involving switching on types is begging for polymorphism to be
applied if at all possible, IMO.

Exactly but how can it be applied in this case?

As we've said: make your middle layer types implement a common
interface, then use the interface from the UI.

Jon