Open GoogleCodeExporter opened 8 years ago
Using `[DisplayName]` would be a mistake; that attribute is used, for example,
to define text on UI controls - so you'd have (in `DataGridView` etc)
`CUSTOMER_ALIAS` instead of `ID`.
Previously, we've always taken quite a strong position of "make the entity fit
the data". I don't have any *technical* issues with us adding our own attribute
to process this, other than it feels a bit "icky" (and that is coming from
someone who uses attributes wildly). I don't have a massive opinion / stake on
the matter, though. In some ways, maybe adding a custom dapper attribute would
make things easier for a lot of people. Not my *preferred* option, but
certainly a better option than looking at `DisplayNameAttribute`
Original comment by marc.gravell
on 26 Jul 2012 at 11:19
We already thought about creating custom attribute but that would create
dependency of Dapper in my multilayered architecture where entities have been
used. So we opted for .net runtime provided attribute "DisplayName".
If Dapper use a custom attribute (in a seperate stand alone assembly) it can
then be referenced across the ntier layer without having a dependency on dapper.
Can we expect this or *better* solution in future dapper.net release?
Original comment by chintama...@gmail.com
on 26 Jul 2012 at 12:21
The best I can offer is a static event: it gives you the MemberInfo, you return
the SQL column name. Then you can write your own implementation. I'm not going
to make dapper look at DisplayName, but you *could* via the event
Original comment by marc.gravell
on 26 Jul 2012 at 1:51
Can you provide a sample as how this event will be raised and how to provide
the matching dbColumn name as input?
Alternative solution can be, Dapper can provide a way to pass a map
(DBColumn-EntityName) as input (optional) to the Read method which can be use
for mapping.
Original comment by SumitSa...@gmail.com
on 30 Jul 2012 at 7:19
Here is my suggestion so far: http://stackoverflow.com/a/11704151/23354
Passing the map to Read is problematic, as that then raises the possibility of
different Read having different Map, meaning I'd need to cache against your
Map. Don't really fancy that...
Original comment by marc.gravell
on 30 Jul 2012 at 10:44
When to expect this solution be part of release?
Original comment by SumitSa...@gmail.com
on 17 Aug 2012 at 1:41
when it gets written, tested and deployed; I'll see if I can get it done this
week
Original comment by marc.gravell
on 17 Aug 2012 at 8:51
The way I achieved this is by making my private variables the same name as the
returned column, then making the Properties English. Not exactly the bases
solution but definitely works and takes advantage of Dapper :)
e.g.
private string customer_alias = null;
public string ID
{
get
{
return this.customer_alias;
}
set
{
this.customer_alias = value;
}
}
Hope this makes sense?
Original comment by Mof...@gmail.com
on 7 Feb 2013 at 9:03
Original issue reported on code.google.com by
chintama...@gmail.com
on 26 Jul 2012 at 11:04