New Model Feedback

[Vaslin]

https://github.com/AuthorizeNet/sdk-dotnet

> We’re introducing the new model as "supplementary" at this time and we would appreciate your feedback. Let us know what you really think!

After one of your developers redirected me to this 'supplementary SDK' and told me to use this vs. fixing a bug in the GitHub where we can't even send in a billing test, I will let you know what a senior developer of 30 years really thinks...

merchantAuthenticationType CustomMerchantAuthenticationType = new merchantAuthenticationType
            {
                name = "5KP3u95bQpv",
                ItemElementName = ItemChoiceType.transactionKey,
                Item = "4Ktq966gC55GAX7S",
            };

Wow, right off the bad I am just stymied by the incredible lack of standardization and naming conventions.  You are first using lower case class/enum names, and upper case variable names.  One property is lower case, the others are upper case.

ApiOperationBase<ANetApiRequest, ANetApiResponse>.MerchantAuthentication = CustomMerchantAuthenticationType;
            ApiOperationBase<ANetApiRequest, ANetApiResponse>.RunEnvironment = AuthorizeNet.Environment.SANDBOX;

And now what is this evil?  Are these singletons that we are setting?    I'm sure you can make a class singleton that makes this much easier for the developer.

var transactionRequestType = new transactionRequestType

I'll just stop posting at this point since someone incredibly used a variable to match the name of the class that actually exists in two completely different namespaces.  At least we're back to using lower case local variable names, but I'm not sure if that's an improvement anymore.

using AuthorizeNet.Api.Contracts.V1;
using AuthorizeNet.APICore;

And then I get to a property in that class

payment = new paymentType { Item = new opaqueDataType { dataDescriptor = "COMMON.APPLE.INAPP.PAYMENT", dataValue = "eyJkYXRhIjoiQkRQTldTdE1tR2V3UVVXR2c0bzdFXC9qKzFjcTFUNzhxeVU4NGI2N2l0amNZSTh3UFlBT2hzaGpoWlBycWRVcjRYd1BNYmo0emNHTWR5KysxSDJWa1BPWStCT01GMjV1YjE5Y1g0bkN2a1hVVU9UakRsbEIxVGdTcjhKSFp4Z3A5ckNnc1NVZ2JCZ0tmNjBYS3V0WGY2YWpcL284WkliS25yS1E4U2gwb3VMQUtsb1VNbit2U

Seriously...  ?

[brianmc]

Hi Vaslin,

Apologies if the mention of the new model was a distraction we have updated the existing code in our future branch.  We do not have a release built with this change yet but you can build the dll from this code base.   https://github.com/AuthorizeNet/sdk-dotnet/tree/future

The new SDK model is still suplementary to our existing code, the reason I suggested that was that you could have an immediate solution.

Another reason for using the new model would be to take advantage of createTransaction API method rather than createCustomerProfileTransactionRequest.  At an API level CreateTransaction is the recommended way to charge profiles (consistent request & comprehensive response) going forward and we will be updating the SDK in the future to use that method (regardless of old model/new model).

Hope this helps,

Brian 

[Vaslin]

Thanks Brian!

You can go ahead and delete this thread.  I looked for that option and couldn't find it.

I am thorougly convinced that I won't be a user of the new SDK.  I assume that I would loose all of the C# goodness that this has to offer, including exception handling and property syntax suger.