I'm working on a client proxy for my WebAPI. I've looked at WebApiProxy but I feel DTOs are unnecessary in my scenario.
I made an ApiProxyBase class that supports basic Get, Post, Put and Delete functionality using generics. Using this base class I've setup an implementation as follows:
public sealed class MyProxy : ApiProxyBase
{
private static readonly string ConnectionString = "MyServiceUrl";
private static readonly MyProxy Instance = new MyProxy(InitializeConnection());
private MyProxy(string url) : base(url)
{
}
private static string InitializeConnection()
{
var conn = ConfigurationManager.ConnectionStrings[ConnectionString];
if (conn == null) throw new InvalidOperationException("MyProxy requires a connection string with the name '" + ConnectionString + "'");
return conn.ConnectionString;
}
public static class Users
{
public static List<User> List()
{
return Instance.Get<List<User>>("users/list");
}
public static User Single(int userId)
{
return Instance.Get<User>("users/" + userId.ToString());
}
public static User Add(User user)
{
return Instance.Post("users/add", user);
}
public static User Update(User user)
{
return Instance.Put("users/update", user);
}
public static bool Delete(int userId)
{
return Instance.Delete("users/delete/" + userId.ToString());
}
}
}
I've read that public nested classes such as this are considered bad practice. To me it feels much cleaner and more readable than implementing each method directly in the proxy like this:
public static List<User> ListUsers()
{
return Instance.Get<List<User>>("users/list");
}
I plan to add more nested classes for each of the datatypes I need, so the semantics of MyProxy.[Type].Add, MyProxy.[Type].Update...etc. feels very smooth when compared to MyProxy.Add[Type], MyProxy.Update[Type].
Are there any good reasons not to go with this approach?
