Oh, I understand now.
What you want is to abstract away the fact that you can be on a windows application, so you have to retrieve through the Server class, or on the server, where you use the Database class.
There are some technical corner cases, like finding Implementations for a PropertyRoute, or finding the ExtensionsQueryTokens for a QueryToken that do exactly this, but for something like Retrieve... I'm not sure.
Even if Retrieve is comfortable to use, its an slow solution.
Your feature will make it too easy to make code like:
if(order.Provider.Retrieve().Company.Retrieve().Country.Retrieve().IsoCode == "US")
Because doing it the right way, by catching the value in the order, or maiking a query like this:
order.Provider.InDB(p=>p.Company.Entity.Country.Entity.IsoCode) == "Us"
will mean too much changes and abstracting the LINQ provider is not a good idea IMO.
When you do myLite.Retrieve(), is time to reconsider your design:
* Maybe you should make a smaller query instead
* Maybe you should change the relationship to make it non-lite
* Maybe you should select entities instead of lites from a query
* Or in the worst case, maybe just Retrieve the lite
Is more a pedagogical reason than a technical one. The fact that we make Lite<T> an explicit public type, as opposed to the hidden Linq to SQL EntityRef<T>, is because making it easy creates slow code.
With Signum Engine, we try to remove all the friction when dealing with the database, but at the same time make abstractions that make clear when you are dealing with the database so you can write performant code.
Feel free to implement you feature thought, maybe you can resist the temptation :)