Open seanconnollydev opened 11 years ago
In the spirit of getting better at thinking through requirements, here are some thoughts to help me steer towards the optimal solution.
Some terminology that might be useful:
Some examples:
_service.Get<Game>("nfl").AndIts<Leagues>("key1", "key2");
_service.Get<Game>("nfl").Includes<Leagues>("key1", "key2");
_service.Get<Game>("nfl").With<Leagues>("key1", "key2");
LeagueRequest leagueRequest = _service.Get<League>("league_key");
TeamRequest teamRequest = leagueRequest.Include<Teams>("key1", "key2")
teamRequest.Include<TeamStats>();
teamRequest.Include<TeamDraftResults>();
Given the above block, I like "Include" better. It works OK with the single line case:
_service.Get<Game>("nfl").Include<Leagues>();
Another option is to use terminology like AsSubResorceOf. For example:
_service.Get
However, I think this will not as easily support the case with multiple sub-resources.
I think the above pattern will work for creating clean requests, but it doesn't really solve type safety.
One thing I can consider is type safety with simple, single resource calls and dynamic objects with anything that requires a sub-resource.
I can also consider a pattern where the parent resource's type is passed as an argument to a sub-resource.
Linq kind of solves this problem I think so it might be worth taking a peek at.
DynamicObject and ExpandoObject both only have run-time checking. I think the problem I am trying solve is somewhat different. Given a method call or series of method calls, the type of result should be predictable so I think there is still an opportunity for compile-time checking. I could create a new type for each combination of call, but I am trying to avoid a proliferation of types and adding unnecessary work.
It is prohibitively difficult to support new API calls. While the classes are relatively easy and safe to work with once established, every new case requires new classes or new combinations of classes (e.g. TeamPlayerCollection, LeagueTeamPlayerCollection, Leagues, GameLeauges, etc.).
I would like to explore new patterns for simplifying the addition of new API calls. Yahoo has defined structures (resources, collections, sub-resources) that can be enforced in code.
The first thing I would like to try is the use of dynamic typing paired with a clean service request builder syntax (e.g. Resource.WithKey("nfl")).