Hi!
Currently ORM.NET is a very powerfull ORM, but the code it generates is somewhat tied to "SQLServer" starting with the types of the Bussines Objects (they all come from System.Data.SqlTypes).
Now, I understand this is because .NET standard types do not have "nullability", but I also feel that ORM.NET should strive for database independence, so, what about start using the type from the Nullable Types Project in http://sourceforge.net/projects/nullabletypes/
They are very powerful, the have been tested, and they can make ORM.NET next version more database independant (of course I think generation with the current SQLServer types shoud continue to be supported for backwards compatibility... perhaps until ORM.NET version 2.0 is released?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, actually in MSDN .NET Documentation it says "The System.Data.SqlTypes namespace provides classes for native data types within SQL Server."
They dont exactly work with all databases (for example some database do not have a "datetime" field, they have a "Date" field, and a "Time" field) For those cases it would be nice to have some kind of "database transparency" by working with times that do not seem "tied with SQLServer"...
But maybe I am too much of a fan of "database independece", I my opinion an ORM framework should try to be as "database independant" as possible, maybe that is why I dont like to use "SQL" types...
I think this is even more important now, that we could have modeled our object model to be on top of a dataset that is getting its data from a WebService, that gets its data from another WebServices, that makes its request using remoting to an application server that then extracts data from five databases.
So, the "real source" of our data is something we should be hidden, so that the bussines logic programmer doesn't have to worry thing like "Is the typing used by the database 4 tiers away compatible with my Bussines Objects?"
Another advantage I think, it is that the Generic Nullable Types are OpenSource, therefore they are extensible, and it is easier to make then evolve to cover unknown needs (the only think a developer can be sure, is that he is going to to develop new code for new unplanned requierents)
But... finally... I think its more of a philosophical thing... I think ORM.NET should also support "standart not-nullable types" because many programmers wont like the idea of using "SQLServer native data types " (for example those that code over Oracle ;) )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Posted before time... sorry, that last paragraph should have been:
But... finally... I think its more of a philosophical thing... I think ORM.NET should also support "standart not-nullable types" because many programmers wont like the idea of using "SQLServer native data types " (for example those that code over Oracle ;) ) and at the same time, they wont like to use Nullable Type because they are not part of the "Standard .NET Framework"
So... what do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since Whidbey aka VS 2005 is adding nullable types, I would like to see any support for nullable types use these new build in CLR types. I think it would be more transparent.
Not sure what the roadmap is here for supporting VS 2005 specific features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nullable data type is need, using 'object' is good, but actually I've created a NullableValue class myself, it support null value, and I don't have to cast to intrinsic data types, enough for me :)
Hi!
Currently ORM.NET is a very powerfull ORM, but the code it generates is somewhat tied to "SQLServer" starting with the types of the Bussines Objects (they all come from System.Data.SqlTypes).
Now, I understand this is because .NET standard types do not have "nullability", but I also feel that ORM.NET should strive for database independence, so, what about start using the type from the Nullable Types Project in
http://sourceforge.net/projects/nullabletypes/
They are very powerful, the have been tested, and they can make ORM.NET next version more database independant (of course I think generation with the current SQLServer types shoud continue to be supported for backwards compatibility... perhaps until ORM.NET version 2.0 is released?
The SqlTypes will work with any database.
We dont actually use SqlReader to pop the data.
However, the advantage of "Nullable Types" is the serialization attribute.
Is there any other reason for using them?
Well, actually in MSDN .NET Documentation it says "The System.Data.SqlTypes namespace provides classes for native data types within SQL Server."
They dont exactly work with all databases (for example some database do not have a "datetime" field, they have a "Date" field, and a "Time" field) For those cases it would be nice to have some kind of "database transparency" by working with times that do not seem "tied with SQLServer"...
But maybe I am too much of a fan of "database independece", I my opinion an ORM framework should try to be as "database independant" as possible, maybe that is why I dont like to use "SQL" types...
I think this is even more important now, that we could have modeled our object model to be on top of a dataset that is getting its data from a WebService, that gets its data from another WebServices, that makes its request using remoting to an application server that then extracts data from five databases.
So, the "real source" of our data is something we should be hidden, so that the bussines logic programmer doesn't have to worry thing like "Is the typing used by the database 4 tiers away compatible with my Bussines Objects?"
Another advantage I think, it is that the Generic Nullable Types are OpenSource, therefore they are extensible, and it is easier to make then evolve to cover unknown needs (the only think a developer can be sure, is that he is going to to develop new code for new unplanned requierents)
But... finally... I think its more of a philosophical thing... I think ORM.NET should also support "standart not-nullable types" because many programmers wont like the idea of using "SQLServer native data types " (for example those that code over Oracle ;) )
Posted before time... sorry, that last paragraph should have been:
But... finally... I think its more of a philosophical thing... I think ORM.NET should also support "standart not-nullable types" because many programmers wont like the idea of using "SQLServer native data types " (for example those that code over Oracle ;) ) and at the same time, they wont like to use Nullable Type because they are not part of the "Standard .NET Framework"
So... what do you think?
Since Whidbey aka VS 2005 is adding nullable types, I would like to see any support for nullable types use these new build in CLR types. I think it would be more transparent.
Not sure what the roadmap is here for supporting VS 2005 specific features.
Nullable data type is need, using 'object' is good, but actually I've created a NullableValue class myself, it support null value, and I don't have to cast to intrinsic data types, enough for me :)
Tiendq,
http://www.fansipan.com