Prev: Reading excel file giving 2 sheets
Next: Consuming web service receiving/returning objects
From: Raj on 9 Jan 2010 01:31
It working fine

Thanks indeed

Regards
Raj

"Peter Duniho" wrote:

> Jeroen Mostert wrote:
> > [...]
> > And that note should also include write-only properties, but it doesn't,
> > because write-only properties are a bad idea to begin with. See
> > http://msdn.microsoft.com/library/ms182165.
>
> I would not go so far as the code analysis rule given. Just as one
> common use for read-only properties are when they are synthetic and it
> doesn't make sense to write the value, so too can it sometimes make
> sense to have a synthetic write-only property, where it doesn't make
> sense to read the value (because it's setting some state that doesn't
> actually correspond to one single thing, or even some stable combination
> of things).
>
> I would certainly agree that it's something to use carefully and only
> when it clearly makes sense. The situations when a write-only property
> is good design are very rare.
>
> In the class being shown here, I think the read-only _and_ write-only
> property is just plain absurd. The whole point of a property is to have
> a single class member that encapsulates a value, and when that value can
> be both read and written, to split that value between two different
> properties seems ridiculous to me.
>
> I suspect that the OP will have much more success with the serialization
> if the class is changed so that it just looks like this:
>
> [Serializable]
> public class Result
> {
> private string data;
>
> public Result()
> {
> }
>
> public Result(string data)
> {
> this.data = data;
> }
>
> public string Data
> {
> get{return data;}
> set{data=value;}
> }
> }
>
> Of course, there still remains the question why the OP has a whole class
> just to wrap a string value. Why doesn't he just serialize the string
> value instead of messing around with the class?
>
> But having a simple read/write property should make serialization go a
> lot better, I would think.
>
> Pete
> .
>
From: Mr. Arnold on 9 Jan 2010 01:33
Raj wrote:
> I shall make appropriate changes as per your suggestions
>
> Thanks indeed for your time and patience
>
> Regards
> Raj
>
>
> "Jeroen Mostert" wrote:
>
>> On 2010-01-08 10:01, Raj wrote:
>>> 1. The object has public properties
>>> 2. I am not using WCF
>>> 3. I am not using XML serialization using only binary serialization
>>>
>> You cannot use binary serialization in a web service. A web service always
>> uses XML serialization. The attributes do not choose the mechanism used;
>> they only provide information to whatever mechanism serializes. If what
>> you're doing is not compatible with XML serialization, it won't work.
>>
>>> This is the object sent/returned:
>>>
>>> namespace WebServiceData
>>> {
>>> [Serializable]
>>> public class Result
>>> {
>>> private string data;
>>>
>>> public Result()
>>> {
>>> }
>>>
>>> public Result(string data)
>>> {
>>> this.data = data;
>>> }
>>>
>>> public string Reader
>>> {
>>> get{return data;}
>>> }
>>>
>> From http://msdn.microsoft.com/library/182eeyhh: "XML serialization does
>> not convert methods, indexers, private fields, or read-only properties
>> (except read-only collections)."
>>
>>> public string Writer
>>> {
>>> set{data=value;}
>>> }
>> And that note should also include write-only properties, but it doesn't,
>> because write-only properties are a bad idea to begin with. See
>> http://msdn.microsoft.com/library/ms182165.
>>
>> --
>> J.
>> .
>>

Why don't you just send back string data? You have one property in the
object and it's string data. You should just have the method return the
string data.
From: Family Tree Mike on 9 Jan 2010 08:49
On 1/8/2010 11:47 PM, Raj wrote:
> Could you please let me know, How do I XMLSerialize the object which needs to
> be sent and return?
>
> Thank you
>
> Regards
> Raj
>
> "Family Tree Mike" wrote:
>
>>
>>
>> "Raj" wrote:
>>
>>> 1. The object has public properties
>>> 2. I am not using WCF
>>> 3. I am not using XML serialization using only binary serialization
>>>
>>
>>
>> I'm pretty sure that nothing shown below changes your service from xml to
>> binary serialization.
>>
>>
>>> This is the object sent/returned:
>>>
>>> namespace WebServiceData
>>> {
>>> [Serializable]
>>> public class Result
>>> {
>>> private string data;
>>>
>>> public Result()
>>> {
>>> }
>>>
>>> public Result(string data)
>>> {
>>> this.data = data;
>>> }
>>>
>>> public string Reader
>>> {
>>> get{return data;}
>>> }
>>>
>>> public string Writer
>>> {
>>> set{data=value;}
>>> }
>>
>> When your object is serialized and deserialized, Reader has no _set_ method
>> and Writer has no _get_ method. They will not serialize, to the best of my
>> knowledge, and therefor the private field data will never be restored.
>>
>>> }
>>> }
>>>
>>
>> Mike

I would make a single property with both the get and sets. Something
along the lines:

private string _data;
public string Data
{
get {return _data;}
set {_data = value;}
}

--
Mike
From: Adam Clauss on 9 Jan 2010 11:01
Peter Duniho wrote:
> Of course, there still remains the question why the OP has a whole
> class just to wrap a string value. Why doesn't he just serialize the
> string value instead of messing around with the class?
Just for the record, had he posted some object with 15 different
properties, you would have told him to reduce it to a simple example :)

-Adam
From: Peter Duniho on 9 Jan 2010 12:32
Adam Clauss wrote:
> Peter Duniho wrote:
>> Of course, there still remains the question why the OP has a whole
>> class just to wrap a string value. Why doesn't he just serialize the
>> string value instead of messing around with the class?
>
> Just for the record, had he posted some object with 15 different
> properties, you would have told him to reduce it to a simple example :)

That's true. But since he never once has posted an actual
concise-but-complete code example, I'm not sure how relevant it is. :p
First  |  Prev  | 
Pages: 1 2 3
Prev: Reading excel file giving 2 sheets
Next: Consuming web service receiving/returning objects