search

devigned / profile-playground

2 stars 1 forks source link

[Bala] Generic Client Factories #3

Open devigned opened 7 years ago

devigned commented 7 years ago

Do we need to create api-version specific client separately and check them in as files? Can these api-version specific client be created with a generic helper method instead? I would prefer syntax like computeClient = GetComputeClient(string profilename) if profileName is null , it should return the latestClient.

devigned commented 7 years ago

I would have loved to have created abstract factories for the profiles, but alas, that would, at worst, prevent us from providing strongly typed clients, and at best, only provide back an abstract base representation of the client. That means, we would not have strong typing and IDE support for specialization of the types and operations across profiles.

If we feel strong typing is not a concern, we can be much more flexible in our implementation.

As for producing the profile specific clients, I would not expect this to be done by hand, but by a code generator. With that said, it's not a ton of code to write (see https://github.com/devigned/profile-playground/blob/master/dotnet/src/Azure/Mgmt/Profiles/2017_01_31/Client.cs).

marstr commented 7 years ago

Don't let idioms get left out of this conversation! For strongly typed languages, I agree that factories in this shape don't make sense. We can't guarantee much about the similarity of clients across API Versions, so it would be hard to strongly type their relationship. However, in dynamic languages this seems like a fairly convenient and intuitive way of handling this.

IMO, the idea and names of profiles should be consistent across languages, but the way you access them should be somewhat flexible.

johanste commented 7 years ago

If a client application has the means to change its behavior based on profiles supported on the server (i.e. using the DLR and/or the dynamic keyword in C#), we should make that possible. So, yeah, there is a sliding scale of strongly typed:ness in many languages/runtimes.

devigned commented 7 years ago

@johanste That's a great idea. Provide an abstract factory for profiles, but also keep the static ones around.

What do you think about this:


// Given a Profile version enum, construct and return the profile
dynamic ProfileFactory(ProfileVersion.2017_01_31) {...};

// Given a Profile definition (set of resource types and api versions) return a 
// dynamically constructed profile
dynamic ProfileFactory(ProfileDefinition definition) {...};