Looks like MS is going after the 'hobbyist' with their new “Express” line of development products. Wonder if this will really stem the MySQL tide or not. Perhaps the SQL Server Express edition will be a better solution than MSDE.
It's official, Yukon and Whidbey are both being slipped to 1st half of 2005.
I am very impressed with RS at the moment. I looked briefly at this stuff a year ago when it was to be part of Yukon and liked what I saw a lot. Now the Report interface is done via Visual Studio and it is very powerful. My days of trudging through Crystal Reports or creating ad-hoc aspx pages may be over. The feature I really like are:
- Ability to use DataSets as data sources (as well as standard ODBC, OLEDB, and ADO.NET Managed Providers).
- The ability to render to different formats (including HTML, PDF, image, Excel, etc.)
- A rich sub-report system for indepth reporting.
- Intuitive UI
While I am just toe deep into the RS pool, I will undoubtedly find wrinkles I don't like. But at first glance I am very impressed.
I've been following some threads on the DevelopMentor .NET Mailing Lists about what is a good solution for O/R Mapping. I am intrigued by a couple of ideas, especially ones that no one seems to be talking about:
- Which is the right direction?
- Do I want to store my object graph in a database?
- Do I want to expose my Database as an object graph?
- What 3rd party applications support these?
- How does ObjectSpaces in Whidbey meet these needs
I have felt a little left out in the cold lately when it comes to O/R mapping. I have spent the last two years on my soapbox about using DataSets (more specifically Typed DataSets) as the answer to Business Objects. I have known I am odds with other data-centric authors/speakers out there, but I still think that Typed DataSets are a good solution now and in Whidbey. But what about ObjectSpaces?
I like what ObjectSpaces is attempting to do. I am suprised by the relative speed that it is able to achieve. A lot of smart people have been working on it for a long long time and it shows. The problem rears its head in a production environment (which no Whidbey code should be in as of now). In my experience, creating the business object layer (O/R Mapping) was only 20% of the job. Tuning it for performance always seems to rear its ugly head. From my experience with ObjectSpaces so far, I am not satisfied that it will be all that tunable.
In addition, I am hesitatant about OPath. For the uninitated, OPath is ObjectSpaces SQL/XPath hybrid search language. After talking with many people at Microsoft, I am still not convinced that an XQuery or XPath solution could not have worked. Why I am worried about OPath? It's all about skill sets. We have asked developers to learn different search skills for years now. We are at a crossroads where developers are unindated with different skills. “Do I learn XPath? XQuery? Hone my SQL Skills?” If ObjectSpaces used XPath or XQuery, we could let them know that the skill is useful outside our specific software domain. “Learn XQuery and you can use that same skill for searching databases (including Yukon and others)”.
So, do I hate ObjectSpaces? Not at all! I think for a very specific problem domain where development time is much more important than performance, ObjectSpaces can make things very easy. This is the case in many corporate development shops. Many shops simply write app after app to solve very small specific issues for in-house customers. ObjectSpaces can excel here. But would I advocate developing a high-performance, online-transactional system with ObjectSpaces? No.
ObjectSpaces is in competition with commercial O/R mapping software. The same foibles that 3rd party O/R Mapping software has had to deal with for years (many in the VB Space), ObjectSpace has to deal with as well. That is, good for time-to-market, bad for tunability.
I want to start a dialogue with the community about these issues. If I am wrong about Typed DataSets, I want to be convinced. Please feel free to comment on this blog entry or e-mail me privately...or call me out on the DevelopMentor lists. At the end of the day I want to be able to give the community helpful advice. If there is a compelling answer here, lets as a community find out what is right.
Anyone else remember the promised "In-Memory Database" (IMDB) that was to be
part of COM+ some years back? Well, Microsoft has finally delivered a first
version of it in ADO.NET's DataSet class.
For those who haven't take a look at ADO.NET yet, don't make the mistake of
assuming the DataSet is a replacement of the Recordset from ADO. DataSets
contain one or more tables. Tables can be setup with relationships, keys,
constraints, etc. Though a real SQL engine does not exist (yet), DataSets do
allow you to re-create some of your databases in memory. If you are attempting
to scale your database servers, please take a look at this very cool
technology!
Ok, this pet peeve is a biggie. Over and over I have seen database schemas
that simply defined the table structures and some stored procedures. Most modern
database systems support advanced features for maintaining database
integrity.
If you are going to go through the trouble to define a database schema,
please finish the job. The database will help you do your job if you simply
define Relationships, Constraints and Triggers. There are good tools for helping
you do this. I really like ERwin or Visio for designing
databases.
The most common error I see in badly scalable database code is reckless use
of the connection object. For all multi-user database programming (which
accounts for most of the work these days), database connections are a limited
resource. Don't let it be your code that is hanging on to his connection way
after you are finished with it. I am *not* saying that all work can be done
disconnected. I am simply asking you to keep in mind that Connections are
precious things. Try to do these two things:
- Open Connections as Late as possible.
- Close Connections as Early as possible.
Most people concentrate on closing their connections early. This is good and
well known. But I have seen more than my share of code (including mine!) that
opened database connections too early.
