See inline:
how about if we want to use stored procedures for insert and update as well?
It will support that as well. VS.NET doesn't care what you want to do
with your stored procedure, they are all accessed the same way (pass
parameters, execute, get results). They are all treated the same way.
how about our "select" stored procedure includes some logic (case when or if
statements based on some pparameter etc.)?
See above. VS.NET 2005 will generate the wrapper, along with methods to
call the procedure (it will create a parameter list which mimics the stored
procedure parameter list).
how about if we dont want always get same column set? do we have to
generate, for each set of columns, another dataset?
You would have to tweak the code for this. However, this is a result of
bad design on the part of the stored procedure, not a limitation in VS.NET
2005. It's like returning object from a method, you could do it, and return
any type you like, but what use is it? It's better to have well-defined
result sets.
i think VS.NET is not powerful enough when it cames to dataset - dataadapter
stuff. more generally .NET platform is not powerfull enough to build an
"true domain model" (kinda Business Object Layer). im waiting for object
spaces untill 2007 :/
I think this is debatable. Needless to say, I strongly disagree with
business objects in a sense (espectially when there is a need for
transactions, given their nature).
BTW ive heard Anders Hejlsberg is working on Object Spaces? is it true?
No, he is not. For all intents and purposes, ObjectSpaces is dead.
Now, it is going to be LINQ, or more specifcally, DLINQ, for working with
database servers. It's in the preliminary stages, so it's hard to say how
it will work, and won't be out for a while.
--
- Nicholas Paldino [.NET/C# MVP]
-
mv*@spam.guard.caspershouse.com 
