Question

Morning all,

I have been tasked with developing a client tool for a cloud web service API (A simple WSDL). I am not a seasoned or even qualified developer, I have an intermediate knowledge of C# and enough I believe to make this work, but I don’t want a solution that just works, I want to build something clean and well coded which another dev can read and understand and which is intuitive.

You may want to stop me there and say “That is something you can only learn through experience.” if that is the case then I can accept that and move on, but if you do have some advice the rest of the details are below.

The solution will be a C# Console application. I have produced a spec for this, it is below:

1.) Create a console application in .NET which has the following
capabilities:

2.) Consume CSV file containing Processed Data OR ODBC
Connection to staging SQL database and read records directly out of
load table

3.) Make the following calls to Zuora Webservice (Asynchronous) ·
SubscribeWithExisitingAccount() · Create() ·
Login() · Subscribe() · Update() · Delete()

(*) Calls marked with this are possibly avoidable,

*it is possible to create a subscription, account and contact with a
single call (Subscribe())

*Create() may be the exception as a scenario may occur where we need
to create an instance of an object with no corresponding subscription.

4.) Report back the success and errors of every record into a CSV
file.

 Mappings will be done on a 1 to 1 basis, where the input file

will have the same column names as the target

Where I lack knowledge is following a design which will make this app make sense and work efficiently. I am not looking for someone to do this for me, what I am looking for is tips on how I can improve on what I am already doing

Currently I am just organically building the solution due to a lack of foresight on jobs like this, so I am also interested in things I can do post development.

ALL Advice and criticism is welcomed.

Thanks in advance,

Matt

Answer 1

Design principles are a big subject, and how to apply them correctly is only something that comes with experience. There’s a lot more of them out there then you’d ever use in a given project, and in some cases using them correctly means not using them at all (or only choosing specific ones that suit the project). The first step is wanting to write good code though, so you’re starting in the right place. 🙂 A couple of things did stand out to me:

2.) Consume CSV file containing Processed Data OR ODBC Connection to
staging SQL database and read records directly out of load table

What you’re going to want to do here is only build the logic that does something with this data once. The most direct way to achieve that is to have your logic expect the data in a certain format (probably business classes that hold the parsed data and that your logic an use).

So what you’ll do is take the input data (CSV/SQL Table/Whatever) and first parse it into your internal business classes. Then you feed the parsed data to your logic that does whatever your app does with it. The advantage here is that you can change the logic once and it will work with both data types, AND if someone comes along later and says “now we need it to read this Excel file” all you’ll have to do is add another parser to get the Excel data into your internal format. No changes to the logic will be required.

4.) Report back the success and errors of every record into a CSV
file.

Mappings will be done on a 1 to 1 basis, where the input file

will have the same column names as the target

Same as above. Don’t assume that you’ll be exporting to CSV forever, make a simple “ReportError” class or some such that holds error details and stick it into a List while doing your processing. At the end when it’s time to output your errors, you can convert that into a CSV. So if this requirement changes and you instead report errors to a web service, you only have to change a small part of the code (and none of it is your processing logic).

There’s a theme here. 🙂 Try to encapsulate logical bits so that if something changes it’s easy to find where that something is in code. If you can learn to do that, you’ll wind up with maintainable code even if you don’t follow any other process or pattern (particularly since as one person you won’t be making huge projects).

3.) Make the following calls to Zuora Webservice (Asynchronous) ·
SubscribeWithExisitingAccount() · Create() · Login() · Subscribe() ·
Update() · Delete()

As a console app, I’m going to question if you actually need these to be asynchronous or not. What do you hope to gain from an async call to Login()? Can your program do anything while waiting for Login() to return?

It’s not that async is terribly difficult, but it IS more to manage then synchronous calls. For a console app from someone whose not that experienced in the technology yet, I’m not sure what benefit you’re gaining to weigh against the extra effort it requires of you.