Finance | Project Operations, Human Resources, ...

class accessor methods x++

(3) Share

Report

Posted on by CU22120935-0

230

Hi,

I think by default class is internal (if we don't define it like code below) and variables are protected by default

[DataContractAttribute]
class CustContract
{
    AccountNum         custAccount;

    [DataMember("custAccount")]
    public AccountNum parmCustAccount(AccountNum _custAccount = custAccount)
    {
        custAccount= _custAccount;
        return custAccount;
    }
}

So for custom services:

1. Is it better to make class public instead?

2. Is it better make variables private instead of protected?

3. For the data member name, is it better to make it capital letter or small letter? i mean custAccount or CustAccount? i think maybe small letter to match json style?

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (5)

Answers (0)

Sort by

Suggested answer

Martin Dráb 239,720 Most Valuable Professional on at

Like (2)

Report
Copy link

Link copied!

If a class doesn't have an access modifier, it's public, not internal. But if you create a new class in Visual Studio, it has the internal access modified by default; it's not created without any modifier.

The answer to "Is it better make variables private instead of protected?" is "it depends". Both have their purpose and what's better (or the only option) depends on the particular situation. For example, if you want child classes access the variable, it must be protected, not public. If you don't want your service class to allow inheritance, set it as final and then there is no point of making fields protected. And so on.

I usually don't override the name in DataMember attribute, but if I do, I use a capital first letter. But what's better depends on the particular scenario, as always.

Was this reply helpful? Yes No
CU22120935-0 230 on at

Like (1)

Report
Copy link

Link copied!

Hi Martin,

Thank you.

for DataMember name, if we don't override the name, then in json, the field will be called parmCustAccount when filling it in postman (i think it's better for the name to appear without the word parm) And we if put it capital letter or small letter, i think postman will allows us to put it either capital or small. But json in general begins with small letter, that's why i thought we should make the name start with small letter (Even though i do also prefer capital letter)

Was this reply helpful? Yes No
Martin Dráb 239,720 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

I don't say that you shouldn't use lowercase. But the whole argument about JSON is not applicable if you access the service through the SOAP endpoint. You may want to optimize the letter case for the real thing (e.g. C# code consuming the web service) rather than Postman. Also, most data contracts are used for other things than custom service (mainly SysOperation framework, including reports). As I said, what's the best implementation always depends on what you're doing.

Was this reply helpful? Yes No
CU22120935-0 230 on at

Like (1)

Report
Copy link

Link copied!
so if it's used by both json and soap, what to do?

which one of those three to choose?
[DataMember("custAccount")] public AccountNum parmCustAccount(AccountNum _custAccount = custAccount) { custAccount= _custAccount; return custAccount; } [DataMember("CustAccount")] public AccountNum parmCustAccount(AccountNum _custAccount = custAccount) { custAccount= _custAccount; return custAccount; } [DataMember] public AccountNum parmCustAccount(AccountNum _custAccount = custAccount) { custAccount= _custAccount; return custAccount; }

Was this reply helpful? Yes No
Martin Dráb 239,720 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

The one that works best for your scenario. You said it was the first one. Just don't forget that Postman is just a test tool; make sure you take the real scenario (how the web service will be used) into account.

Was this reply helpful? Yes No