-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fluent API #6
Comments
Mongo driver for .NET implements such a thing, by the name of Specifically the MongoDB.Driver/FilterDefinitionBuilder.cs Disclaimer, I've never used the mongodb driver for windows, it just seemed obvious it had this. |
Just gave a read to the fluent_api branch, and I'm a bit confused about what your trying to achieve exactly. And maybe you're too. The method chaining syntax one usually sees goes something like But I believe what you're trying to achieve is different, you want proper C# like query syntax. You might be mixing the two. The former is easier to get right. |
What I really want to achieve is clear separation between Eve internals and the client API. In your first example, you are passing I am not a fan of "very fluent" queries like the one in your first example. They soon get very long, hence hard to parse (at least for me). Simply exposing a Right now, with the current API, achieving something like that would mean passing raw, Eve-understandable strings to the GetAsync method, which is very limiting if, say, the client developer knows nothing about the server internals (which is my use case, by the way). |
Yes, But, I guess we're in sync on the goal. I am not a big fan of the "very fluent" queries either, but the truth is they are very good for this kind of thing, for a number of good reasons. Where expressions will always leave you short. A quick example I can come up that lambda expressions won't make it is mongo geo queries, but there are plenty of others I'm sure. The problem I originally noticed in your example, is that your kinda mixing the APIs together.
is really not much different to:
ParsingAs for parsing the "very fluent" APIs, not sure I'm following you on that one. I'm not going to be able to explain an implementation of such API in this post, but to put it quickly I would define a set of interfaces (that would basically enforce static semantics, like after All those methods just have to return I have to disagree when you say:
I say different, if the client is filtering data he should be very aware of the data structure he is querying, otherwise how would he build the query in the first place? I've worked SQL database for years, the first thing you do is a -- One improvement would be not using strings to pass fields, but rather use a more strongly typed approach, like:
Do note:
|
What I meant by parsing, I guess, is "readable/processable" to the eye. You have a good point on complex queries (geo, etc.). "Client not knowing underlying data structure": I mean eve internals. Like, I do not want the client programmer to be forced to use On the interfaces yes, right now I don't have them in place but once things get more complex they should probably be there. Keep in mind, this is just an experiment at the time being, and this discussion is exactly what I was looking forward to. |
About the readable part, I get it. But I was making a point when I said
database queries end up being amazingly unreadable. Thats not to say one should not improve the situation. And yes, the Eve internals are Eve internals, and should be dealt with internally. The point I was actually subtly making is that
Love it, never done this sort of query chaining thing, but always seemed a fun challenge. |
for some thoughts https://nosqlbooster.com/FluentQueryAPI Just gave a better read, looks like a fantastic guideline/starting point, what do you think? And actually the syntax you propose is not that difficult to be leveraged in the API I propose as syntax sugaring. |
I'm looking at how the mongdb driver addresses 'fluent' (linq), and it looks they went more less the same direction as I did in my first experiment: http://mongodb.github.io/mongo-csharp-driver/2.5/reference/driver/crud/linq/ |
Interesting. But they didn't solve the geo queries issue I've pointed out; it's just left out. And they still have the weird reflection hacking I've mentioned to get the properties names rather than values: as I've said there's no way to do it statically. When they have I think we have 3 proposals on hand: // loosely typed
Get<T>().Where("born").GreaterThan(DateTime.Now).Asc();
// strongly typed
Get<T>().Where(t => t.Born).GreaterThan(DateTime.Now).Asc();
// expression like
Get<T>().Where(t => t.Born > DateTime.Now).Asc(); Both Probably some signature like: // loosely typed
ICallSomething Where(string property);
// magic happens
// strongly typed
ICallSomethingElse Where(Func<TSource, TKey> property);
// return Where(nameof(TSource.TKey))
// expression like
ICallSomethingElse Where(Expression expression);
// good luck.. :)
// and probably return Where(nameof(LeftTSource.LeftTKey).Equal(RightValue) I'm sort of on a chalenge to code only on an Android tablet, and I'm not getting much luck with mono on Android. Thats my struggle right now to start coding on this. |
To be honest, the difficult part in leveraging those 3 looks to be enforced semantics with interfaces, which is something I find very nice. |
Would be nice to have a fluent API, whereas now we are just passing arguments to the GET method. I guess what I have in mind is something like
client.Get(url).Where(customer => customer.Name=='John').Sort(...)
.That's going to be quite a lot of work, and I am not sure it is really worth it. Also, I don't have the time to work on this right now. Up for grabs!
The text was updated successfully, but these errors were encountered: