Rants Tagged with “ORM”
1 (Total Pages: 1/Total Results: 10)
If you havent voted, please feel free to vote for what data access strategy here:
http://wildermuth.com/2008/03/21/Data_Access_Strategies.aspx
For those who were interested in the results:
One thing that I took away from this is that some strategies did not get any votes (and I expected them to) like CSLA. I think that's a product more of the fact that Rocky's readers probably don't read my blog...so the poll is very unscientific. I was surprised by the sheer number of LINQ for SQL respondents and the big Entity Framework numbers. Both being new technologies, I didn't expect there to be much usage yet. Go figure.
I had interesting conversations with a number of people about different data access/ORM strategies at MIX recently and was trying to understand where people are spending their efforts in consuming data. The conversation was essentially a discussion of who is using what to access data in .NET applications. I had assumed that certain solutions were widely used and others were not but I didn't have a good idea of what the market was really like. To help me with this I am asking you (my readers) to share with me where you are investing time in data access by taking the following poll:
My new article on how to get started with NHibernate is up on DevSource. Check it out.
I am currently doing a bunch of evaluations on OR Mappers, Code Gen and Business Object Frameworks for my new book. If anyone knows about anything great that might go unnoticed, please drop a comment or send me an email!
Thanks!
I haven't had time to look at this new round of discussions about where DataSets fit into the data world. I am still reformulating my ideas around DataSets after meeting with Microsoft and being told that they did not want to encourage use of DataSets in place of business objects.
I have also been using CSLA.NET at a client and it has some good ideas about entity mapping in general, though it has a number of well documented downsides as well. As Rocky would probably tell you, CSLA has it's place in some architectures but was not meant to fit into all solutions.
My plan is to unveil something new that attempts to address the shortcomings of all the camps (ORM, DataSet, Custom Business Entities), but I am not ready to present it yet. I think we need a good solution for Whidbey and beyond and I don't see that coming out of Redmond (don't get me started on ObjectSpaces ;).
Check out this excellent post on logical vs. physical data tiers.
After reading Rocky's blog about DataSets and Web Services, I am afraid that he is falling into the same trap that other's have (including the emminently qualified Tim Ewald) with respect to DataSets. DataSets work well in Web Services but not by default. As I mentioned in:
http://wildermuth.com/content.aspx?id=rantview&rantid=7
The reason I like DataSets across Web Services so much is simple. On my side of the interop wall, I can treat them like a set of data-centric objects. But when I expose them via Web Services, I can treat the entire DataSet as a document. I like doc-literal web services. The magic here lies in the fact that the schema of the DataSet can be simply described with XSD. In fact, for non-typed DataSets that can be described inline with WriteXmlSchema() (so it can be interpreted on the other side of the interop wall).
For typed DataSets it gets even better. An XSD is the source of Typed DataSets, so exposing your XSD to describe your 'document' is a natural way of doing things. In fact, if you're not using ?wsdl for your .NET web services (which you shouldn't!), you can refer to the .xsd to describe the types that your web service expose.
I am passionate about this because creating web services to banty around your business objects is fine, but seems wholly unnecessary. I hope I can get Rocky to see the light.
Addendum:
I love Sahil's discussion of this too:
http://dotnetjunkies.com/WebLog/sahilmalik/archive/2005/01/23/47832.aspx
Recently I was talking with Rocky Lhotka and he said something interesting:
“Just when we got good at Client-Server, they switched things and had us doing n-Tier applications. Just when we got good at n-Tier development, internet applications took off.”
In my opinion he is right. It is interesting because client-server and n-Tier applications still exist, especially in enterprise development. I think we're good at client-server and n-Tier. The problem is that I think that much of browser based development attempts to apply n-Tier development.
What do I mean? In simple words, the web server is the middle tier. The browser is the client tier.
The idea behind n-Tier development is being able to separate the data work into a tier that can be scaled out. Luckily we know how to scale out webservers (into farms). Since we are securing webservers, we can isolate security issues from the client...just like we've done in n-Tier development.
I've had time lately to think about the nature of data in development lately. I've been talking with Rocky Lhotka and Michael Earls about it (as well as number of others) about the issues with dealing with data in applications.
The first camp is all about writing Business Objects. In this camp, you write classes that encapsulate the data, the data access and business rules about that data. This camp was the way to do it for years now. It proliferated in the Client-Server and n-Tier architecture camps.
Rocky Lhotka espouses his excellent CSLA.NET framework. If you are going the business object road, I wholeheartedly recommend it. It is designed around allowing object to exist locally or on separate servers through remoting.
The second camp is that data is all about data, so data is just a message to some system. With the excitement around Service Oriented Architectures (SOA), this view is starting to prevail.
Somewhere in the middle is where I sit. I think that data and business rules belong together, but the data access can be disconnected from it. So this is the interesting fact in my opinion...there are reasons to have the data access separated from the end users' machines (so perhaps remote data access), but once in the client, you want to have the business logic (and schema) as close to the client as possible. The closer it is to the client, the better it should scale. I don't like to see finely grained data access happening. Even in client-server apps, the more coarsely grained the data access, the better it should scale IMHO.
There is more I want to say on this, so stay tuned. I will be posting every day about this.
Tomorrow: “n-Tier, gone tomorrow”
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.
