Experiments In Writing - All Comments

re: Using an ORM? Think Objects!

laughing John — Mon, 15 Sep 2008 09:03:37 GMT

I think the only thing that these ORM frameworks show is that we have a crying need for a proper OO database. I know they're already out there but I think most companies (probably wrongly) are wary of anything that doesn't come from the big boys like MS/Oracle/IBM/

The worst thing about a lot of ORMs (Hibernate/NHibernate perhaps being one exception) is that they are intrusive and they tend to lead to an object design that mirrors the database rather than the other way round. The business objects often need to inherit an interface and/or have attributes and often have an interface forced upon them that may not be appropriate to the business requirements.

Of course other technologies like serialization and binding have a similar effect of placing requirements on the objects.

re: Using an ORM? Think Objects!

Scott Rudy — Sun, 27 Jul 2008 06:17:48 GMT

I personally would like to see Microsoft abandon some of this in favor of code generation. ORM is nice and flexible, but it just adds another layer of complexity, in my opinion. I think it would be better to design a POCO and allow templates to be used in forward generation of a data access layer, table and stored procedures. No fancy, bloated data objects or abstraction layers needed, just plain old maintainable code.

I'll admit I haven't given the Entity Framework a real chance yet, but I am quite confomfortable where I am. I don't think anyone was happier than me when the 2.0 framework added what is perhaps my favorite framework feature to date, the BindingList<T>.

IList Performance Decrease « Tales from a Trading Desk

IList Performance Decrease « Tales from a Trading Desk — Wed, 16 Jul 2008 22:57:40 GMT

Pingback from IList Performance Decrease « Tales from a Trading Desk

re: Using an ORM? Think Objects!

scott-allen — Wed, 16 Jul 2008 17:12:32 GMT

Max:

I think you are correct - LINQ to SQL is the quick and dirty solution, especially when compared to the features in EF.

The statement you highlighted was a personal opinion (or hope) that LINQ to SQL will mature a bit further and give us some additional mapping options. EF comes with it's own set of issues and I personally prefer the design of LINQ to SQL - it's just not usable in many scenarios because of the limitations.

re: Using an ORM? Think Objects!

Max Schmeling — Wed, 16 Jul 2008 16:42:54 GMT

I'll admit that I may be misunderstanding you, or maybe the purpose of Linq-To-SQL, but I have a comment on this part of your post:

"LINQ to SQL also needs some additional mapping flexibility to truly separate the object model from the underlying database schema – hopefully we’ll see this in the next version."

Linq-To-SQL isn't supposed to separate the object model from the underlying database schema. It is supposed to be a quick and simple way of getting the data to and from the database. The Entity Framework is the tool, or set of tools, that is supposed to allow you to completely separate the object model from the database schema to work with your objects in a more intuitive and logical way.

re: Optimizing LINQ Queries

Chris Nahr — Tue, 15 Jul 2008 07:49:31 GMT

Thank you for a very enlightening post. Who would have thought that a let clause would be so expensive?

re: Hello, .NET Source Code

Kerem Kusmezer — Wed, 06 Feb 2008 07:42:00 GMT

NET Mass Downloader

Welcome to the .NET Mass Downloader project. While it’s great that Microsoft
has released the .NET Reference Source Code, you can only get it one file at
a time while you’re debugging. If you’d like to batch download it for reading
or to populate the cache, you’d have to write a program that instantiated and
called each method in the Framework Class Library. Fortunately, .NET Mass
Downloader comes to the rescue!

It is live now under :
http://www.codeplex.com/NetMassDownloader

Go Grab Your Copy.

re: Silverlight Subtleties

Niks — Wed, 28 Nov 2007 03:09:00 GMT

Good Post . ITs useful for me.

Appriciated

Niks