>>>>>Yes. In .Net it is considered a good practice to not prefix the variable/type with the type. Just use the name.
>>>>
>>>>Please provide a link to the grail for .NET naming conventions.
>>>>
>>>>From what I'm hearing here, If you have a customer class it would be Customer. If you have a customer form it would be what.. CustomeR?
>>>
>>>
>>>LOL.. I would hate to work with you ... Why do you fight against .net so? ... If you don't like it, code in something else....
>>
>>Likely to happen extremely shortly (like today since I'm likely to quit my current job today).
>>
>>

>><Rant ON>
>>I'm now trying to transition from vb.net and asp.net to c#/Entity Framework/LINQ/Silverlight/RIA on a project. 
>>
>>Silverlight is another giant leap in not ready for primetime development environments (if you want to work with data anyway). Combobox bound to data in a datagrid? Why would someone want that? Stored procedures? In Silverlight? Apparently they aren't BEST PRACTICES anymore since the Domain Service doesn't support them. 
>>
>>Wading through piles and piles of incomplete/incorrect blogs and other posts from drooling geeks around the world trying to show the hacks to get things to work since there is no direct way to do it.
>>
>>What happened to RAD, or developer productivity? What a load of $hit.
>>
>></Rant OFF>
>>

>What have stored procedures to do with Domain Services ?

From the drooling geek blogs I read, Since you can expose stored procedures in EF (and manually include them and their complex types), you should be able to include them in the domain service (manually with lots of cryptic code). I've almost got that working except I still can't iterate through the results of one (after creating a query and loadoperation).

If there is an easier way to use a stored procedure than via EF/domain Service, I'm very open to jumping on it.

Stored procedures were a BEST PRACTICE for efficiency and security BTW. Probably not anymore but That is what my database uses.