views:

48

answers:

2

Assume following:

public class MyFunkyTable : DbObject
{
    // this class will be generated
}

public class MyFunkyDomainObject : DomainObject
{
    // this class will be custom-made
}

public class MyFunkyMapper : Mapper<MyFunkyTable, MyFunkyDomainObject>
{
    // this will be custom mapping code due to wired abstraction and ... "supercool" db-system
}

in general we do following:

MappingHelper<MyFunkyTable, MyFunkyMapper, MyFunkyDomainObject>.GetSingle(...);

bu the repeating of the generic constraints is a bit an cumbersome (MyFunkyMapper already specifies the generics..)

Is there any way to do something like:

MappingHelper<MyFunkyMapper>.GetSingle(..);

edit:
I've already came up with an idea: usage of extension methods, but this isn't what I want...

+3  A: 

Why don't you just do something like

var item = mappers.Get<MyFunkyMapper>().GetSingle(...);

This assumes that Mapper<TTable, TDomain> has a GetSingle<TDomain>(...) method. If this is the case, type inference will figure out the generic argument to GetSingle even if you don't write it.

BTW, have you considered using AutoMapper for mapping purposes instead of rolling your own?

Mark Seemann
this is not the case ... we want our mappers only to map, not to contain any db-call (neither exclusiv per instance programmed, nor per derivation of the base-class). and: for autoMapper fans (i'm one either) i've added a note saying: this will be custom mapping code due to wired abstraction and ... "supercool" db-system --> atm no chance for autoMapper.. sry
Andreas Niedermair
+1 for AutoMapper
Jeremy McGee
@dittodhole: I'm not sure I understand the problem, then. Would it help if we renamed the GetSingle method to MapSingle?
Mark Seemann
nope - cause MappingHelper does the communication with the DB and uses a FromDB/ToDB-method of the concrete mapper
Andreas Niedermair
Notice that my example doesn't use any MappingHelper. The `mappers` variable can be whatever you want it to be. If you want to abstract away the DB communication, you can make it an abstract class or an interface. It's really perpendicular to your question on how to simplify the generics of your API.
Mark Seemann
hm ... well ... after thinking about it for some time, your solution might be perfect if we add following: implement extensionMethods in your `mappers` class and let `Get<T>` return a mapper. then i can use the extensionMethods without being too aware of `using` s
Andreas Niedermair
+1  A: 

I think you can't. The compiler can infer type parameters by looking at the arguments of a function, but that's it. Since you do not pass any parameters, you won't be able to use type inference.

A shortcut I might suggest is a lesser-used functionality of the "using" keyword. Just add at the top of your file (next to the normal using's) this line:

using TheMapper = MappingHelper<MyFunkyTable, MyFunkyMapper, MyFunkyDomainObject>;

And then in code

TheMapper.GetSingle();

This shorthand can come in handy if a file accesses one or few mappers.

Another idea - instead of MappingHelper, why not add all of those things in the Mapper<T1, T2> class? Then you will be able to use

MyFunkyMapper.GetSingle();
Vilx-
i haven't thought of the alias yet ... but this will cause every file, which uses the mappingHelper, to add such an alias. why i do not want to add the db-communication to the concrete mapper has a simple reason: exchangability and redundancy
Andreas Niedermair