Allow nameof as Property in anonymous type

[YairHalberstadt]

In dapper, and presumably other frameworks it is common to do the following:

(Dapper-simple-crud used in this example for simplicity)

var results = connection.GetList<MyType>(whereCondition: new { MyProperty = 42 });

In almost all cases, the properties on the anonymous type will match the name of a property on the generic type parameter.

It would be helpful if you could use nameof to define the property on the anonymous type, which would reduce the chance of spelling errors, and make it easier to rename the field.

var results = connection.GetList<MyType>(whereCondition: new { nameof(MyType.MyProperty) = 42 });

[HaloFour]

Where this might be confusing is that nameof produces a string constant, but anonymous types don't allow string constants to be used as identifiers for the property names. Otherwise I think it's an interesting feature.

You could accomplish something similar with an analyzer which inspected these specific methods and tried to map the shape of the generic type with the anonymous type being passed as an argument.

[alrz]

this is why we have expression trees? you have all that information from x => x.Prop == 3 and more.

[YairHalberstadt]

@alrz

Dapper doesn't use expression trees. As a result of which is much simpler, and just works. You don't need to worry about whether or not this particular expression has been implemented.

[qrli]

Other than anonymous class, MongoDB's C# API uses lambda instead, which preserves type checking:

Collection<MyType> collection = ...;
var list = await collection.Find(x => x.MyProperty == 42).ToListAsync();

So, it is more of an API design choice to me. The Dapper way is very interesting, though it surely need some assistance to protect from typos and rename refactors at compile time than run time.

[YairHalberstadt]

@qrli

Indeed, but the simplicity of dapper is what has made it so popular is a micro orm. Dapper does one thing, and it does it really really well - it's really good deserialising from a database query to a typed object. I don't think it's interested in becoming a full scale ORM.

To give an example as to why Linq to expressions isn't as straightforward as it may seem at first, this is the full signature for dappers Query method:

public static IEnumerable<T> Query<T>(this IDbConnection cnn, string sql, object param = null, ...);

It takes an arbitrary string of SQL and an arbitrary set of parameters to the sql, passed in as properties on a (usually anonymous) object.

Therefore there's no guarantees as to where the parameters would come from, or how many parameters there are, which I think would make Linq to expressions unwieldy ( you would have to accept a List<Expression<Func<object, bool>>> and then cast the object to the type which declares the property you need).

[qrli]

@YairHalberstadt The general form of Dapper's Query uses the anonymous class members to substitute sql variables in the sql string, e.g. @tableName, @thresholdValue, which are not always type members. That will be beyond what your proposal can solve.

I like Dapper too. Some type checking would indeed be great. But I don't have a good idea.

[YairHalberstadt]

@qrli

Certainly this doesn't solve all problems. But I imagine it could take care of a majority of use cases.

@mgravel, I wonder if you have any opinion on this feature request? Do you think it would be a useful addition to dapper?

[YairHalberstadt]

Sorry, I meant, @mgravell I wonder if you have any opinion on this feature request? Do you think it would be a useful addition to dapper?

@mgravel apologies for spamming you.

[mgravell]

my thoughts: personally I only use the "core" of dapper, i.e. where you're directly invoking either local SQL or a stored procedure; examples:

var list = con.Query<Customer>("select top 50 * from Customer where Region=@region",
    new { region = request.Region }).AsList();
...
var list = con.Query<Customer>("GetCustomersByRegion",
    new { region = request.Region }, commandType: CommandType.StoredProcedure).AsList();

And in those cases, the names in the anon type need to match the local SQL, which is not necessarily anything at all related to the type. If it renamed itself because you used f2 - that would be a bad thing. Meaning: renaming request.Region does not mean that my SQL has changed.

The example that is prompting this looks a bit more like contrib / rainbow? I'm really not convinced of the benefit of complicating the language for what looks like a very niche scenario and which has a lot of crossovers with - as noted - expression trees (in more "complete" ORMs).

So: personally I don't think I have a horse in this race.

[HaloFour]

@mgravell

Sounds like that lends credence to the notion that this would be better served by an analyzer, one that would specifically recognize Dapper conventions. For example, it could theoretically catch the following mistake:

var list = con.Query<Customer>("select top 50 * from Customer where Region=@region",
    new { regoin = request.Region }).AsList();

by interpreting the SQL and noting that the anonymous type does not include a property for each of the parameters.

[YairHalberstadt]

@mgravell

Thanks for your feedback.

In that case I usually use nameof in the sql as well. Whilst they aren't necessarily in sync, I'd rather try and keep them in sync if possible, and have a runtime error if I don't.

If course every use case is different, and the idea of this feature is that it does give you a certain amount of flexibility. However I can see it's kind of niche.