Part one of a series about an OData library I'm building #8
Conversation
| @@ -0,0 +1,186 @@ | |||
| Creating a .NET OData library | |||
There was a problem hiding this comment.
I've read through your post, the linked tutorials, and some of the source in your repo. Right now I think I understand how consumers use the client code. I don't quite understand the endpoints on the service side yet, but I'm sure I'll get there. I can theoretically understand some of the benefits this library provides, but I don't know C#'s tools for OData queries well enough yet to understand how this can be helpful for practical development.
Overall, this post reads really well, and the library you've written seems quite complete and well written! That library looks like it was very difficult to write and took a lot of effort (+100 passing unit tests...wow)! I'm excited to read more about OData, try out Microsoft's C# tools around the OData spec, and understand your code more. I'll post more comments when I understand these concepts and implementations better.
I think this post is solid for release. How do you want to release this series? Do you want to write all the posts, then release them successively? Do you want to release one at a time? Are you concerned that future changes to the libraries' API may make these posts confusing? I'd guess this libraries' API will change because it hasn't gotten much usage yet.
There was a problem hiding this comment.
Glad you like the post/library! My thought was to release these as I go, with the idea of documenting the process of developing the library (although development is ahead of the posts themselves so I have some benefit of hindsight).
Thus, I'll cover the public API when development gets to that point. That said, your comment highlights the fact that this post doesn't currently do a good job of showing what that API might be like, which would help readers understand the goals. I'll add some content on this.
There was a problem hiding this comment.
Explaining what the API will look like make sense to me. I think it would go well near the "This involves implementing a multi-step request pipeline involving steps on both the remote service and the client" section
There was a problem hiding this comment.
The only other thing that may be useful is to explicitly contrast the your API with what currently exists. I know you've created links, but you could be more aggressive by including a code snippet or pointing your readers to these links if they want to contrast the differences. With or without that addition, think this post is great and ready to go!
There was a problem hiding this comment.
I'm hoping to end the series with a post detailing the finished library. When I have a more complete API, I think it will be easier to show the differences. It's also hard in this case because on the client side you use visual studio to auto-generate a bunch of code, so it's not like you can just compare and contrast similar APIs.
|
|
||
| <pre> | ||
| // MVC example. A caller might hit this action method with something like /Customers?$filter=Level eq Silver&$select=Name | ||
| public ActionResult Customers() |
There was a problem hiding this comment.
So one of the things I don't understand is /{Entity} restriction (i.e. /Customers in this example). It seems pretty cumbersome to have to include an entry point for every entity. I'd think the pattern would be more like /{DataContext}/$from={entity}. Perhaps I'm misunderstanding the use of exposing only these entry points or I'm misunderstanding the flexibilty of these entry poins.
There was a problem hiding this comment.
That's not a restriction you get with my library, but it's part of the normal OData approach. In general, I'm not convinced that exposing your whole data model via a web service is all that useful (but that's what you typically do with OData). Instead, I like the ability to have IQueryable web services for anything you might be returning.
No description provided.