Don't know if you guys have seen this or not, but if not i figured you might be interested.

Gentle.NET - An Object Persistence Framework

If you have l lot of time on your hands...

But, aren't you happy with LLBLGen Pro and do you need another O/R mapper?

I saw this too, and saw these downsides:

Lots of coding involved. Relies on Attributes to objects, and has no code generator. It might work well for brand new applications/data structures where you control everything, but that's pretty rare. Requires manual sync of code between objects and data structures. Very new with limited feature set.

Could someday be a good project, but that it's open source means no one is incented to make it competitive. Not likely to exist two years from now. The developers seem entranced with making it Mono-compatible, which means they're committed to it being a rev or two behind the current .NET release, and to never making money. I don't want a tools vendor that doesn't want to make money. I want to, and I want all my tool partners to as well. I ain't in this just for the jollies, or to prove I'm a man, or to promote Mono.

Another product is DeveloperExpress eXpress Persistent Objects for .NET at http://www.devexpress.com/?section=/products/NET/XPO. Labels itself as "Easy to Use and Highly Productive," though it's neither. I wasted two days playing with the samples and never got them to hit the database. DevExpress has always been a great Delphi development shop, but they're known for not getting it right in the first few tries. Delphi developers don't seem to mind that. However, if they hit the mark with the featureset they propose, they might really have something. Again, a situation of complete control, because it wants to generate table structures based on object structures. This is not realistic. In thier 1.5 release they allow backing into existing stuctures, but it's poorly implemented. Read their newsgroups and you'll feel the customer heat, and quickly sense that DevExpress doesn't respond quickly, if at all.

Not shopping around, but I like to keep current with the .NET tools out there. It's worth a few hours to get to know a product if it could save me hundreds and hundreds of hours.

I think i'd have to agree with you there. Just thought it sounded like an interesting project.

Thanks for your comments on eXpress Persistent Objects, i'm glad now that i didn't waste my time and money on it

Thanks for your comments

Glad to help. Actually, I'm going for the record number of posts by a non-administrator on this board.

My favorite thing to learn about right now is WinFS, the new filesystem in Longhorn. This is going to be huge, and will change applications development (primarily fat client) in a fundemental way.

Application save things. They search for them once their saved, and they edit them afterwards.

WinFS is effectively a SQL server. You create a folder as your userstore, and start saving objects. You package with your application some bits that validate the properties of the object, and some XML schemas that describe metadata for searchable properties. When you save an object, it becomes visible to the operating system because you've told it how to deal with that object, and how to search for it based on the Schema.

These objects can be placed in folders, which are in reality just SQL views of a collection of objects. An object can be placed in many folders ( unlike today's filesystems), so that it can be a part of many collections.

Let's get specific. I create an object for motorcycles. I describe them completly, and allow the object to be saved. I provide an interface for editing and saving individual motorsycle objects. I create an XML schema that says that the brand name, color, and model number of the motorcycle objects can be searched, and provide bits for how to read those attributes from the binary (on disk) single motorcycle object.

Now, when I want to search for motorcycles I can do search from the Start menu and type in characteristics about motorcycles (brand name, color, etc.) and it will find them anywhere on the filesystem.

A much better example of this is at

http://msdn.microsoft.com/Longhorn/productinfo/conceptvid/default.aspx

in the Commercial Real Estate video. It provide a specific example of real estate parcel and transation information being stored to (conceptual) folders and emailed around. The user just sees it as a complete deal including data (from the saved objects), and the forms needed to close the deal, not as a word document, an excel document, a picture, etc., in a zip file.

It's going to change the way things are done. The trick will be re-training old dogs to think in this way. I remember the pardigm shift to Windows 95, and trying to get developers to think like the new interface wanted. People new to computers who had never used anything other than Windows 95 loved it, old hands hated it (and grew to love it.) The same will happen here. The shift will be monumental, and short-sighted people will hate it for years. But it will be a blessing. Check out the videos and you'll see how people will interact with software five years from now.

Enough rambling.

Other good sources for WinFS information:

http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/WinFS/default.aspx

http://msdn.microsoft.com/theshow/episode041/default.asp

http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/winfsdevpersp.asp

And, of course, http://msdn.microsoft.com/Longhorn/understanding/pillars/WinFS/default.aspx

Thanks for your great comments on XPO, Scott

swallace wrote:

Thanks for your comments

Glad to help. Actually, I'm going for the record number of posts by a non-administrator on this board.

hehe

My favorite thing to learn about right now is WinFS, the new filesystem in Longhorn. This is going to be huge, and will change applications development (primarily fat client) in a fundemental way.

I wish it was that way, however it's a little less drastic as it seems. At first I thought it would be something like this: - you have several data elements in your filesystem: a picture, a block of sales data, some raw text - you open Word. Instead of creating a Word doc, you create data-elements and combine other data-elements to a new 'View'. A word doc is then thus nothing more than a view on the data in your file system. This has obviously great benefits, as you can re-use data without restrictions like file formats.

But what I understand from it is that it isn't setup like this (please correct me if I'm wrong ), but like this: - word document with various data elements lives in the file system - you can specify properties you define with this data object. - the properties allow you to retrieve the complete word document via a query.

Now, of course this is great, and perhaps a more logical way to make the transistion from file-oriented data-storage to data-element-oriented datastorage. But I don't think a lot of applications will have a lot of problems with saving data into WinFS.

WinFS is effectively a SQL server. You create a folder as your userstore, and start saving objects. You package with your application some bits that validate the properties of the object, and some XML schemas that describe metadata for searchable properties. When you save an object, it becomes visible to the operating system because you've told it how to deal with that object, and how to search for it based on the Schema.

These objects can be placed in folders, which are in reality just SQL views of a collection of objects. An object can be placed in many folders ( unlike today's filesystems), so that it can be a part of many collections.

This last thing is indeed a very big thing as it seems, however on Unix you can have links to files in whatever folder you like and it behaves as a normal file, but it is a link, so semantically I think it is somewhat the same (but stored very differently of course )

Let's get specific. I create an object for motorcycles. I describe them completly, and allow the object to be saved. I provide an interface for editing and saving individual motorsycle objects. I create an XML schema that says that the brand name, color, and model number of the motorcycle objects can be searched, and provide bits for how to read those attributes from the binary (on disk) single motorcycle object.

I see a link with Infopath coming up! (or infopath technology: create edit forms for objects fast and easy)

Now, when I want to search for motorcycles I can do search from the Start menu and type in characteristics about motorcycles (brand name, color, etc.) and it will find them anywhere on the filesystem.

A much better example of this is at

http://msdn.microsoft.com/Longhorn/productinfo/conceptvid/default.aspx

in the Commercial Real Estate video. It provide a specific example of real estate parcel and transation information being stored to (conceptual) folders and emailed around. The user just sees it as a complete deal including data (from the saved objects), and the forms needed to close the deal, not as a word document, an excel document, a picture, etc., in a zip file.

Hmm, sounds like I have to correct myself a few lines back I'll check out the video, thanks for the link

(edit, hmm, everybody and his brother are d/l-ing patches as it seems . Will try later)

perhaps a more logical way to make the transistion...

Yes, it seems to provide a good transition. I don't expect Word documents to be implemented that way, but I see that they are building Contacts (People) right into the OS as an object, with all the attributes searchable. Things don't have to change, but where it's helpful, they can. I don't suspect I'd offer to the OS all the attributes of the objects I create, but I would for many of them. Once available to the OS, they become available to other applications (assuming DRM). My motorcycle objects can be used in any application.

however on Unix you can have links to files in whatever folder you like

Yep, but the difference is in the kind of links. I'm still understanding the terms, but there the kind of links in UNIX are physical (meaning written as a file) whereas the links in WinFS can be either physical or virtual, and can contain many more attributes. I'm really fuzzy here, but some of the documentation describes it better. An example is of a subset of motorcycles (from the Motorcycles User Store) used in another application. The analogy is to a filtered view for the consuming application. If the user then wants to save that list it becomes physical, and picks up the attributes of a folder, including naming, versioning, etc. It's more than links, but I can't come close to explaining it properly.

The section called "Relationships in WinFS" in the document "A Developer's Perspective on WinFS" at:

http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/winfsdevpersp.asp

describes "Reference relationships" as "different than holding relationships because they can still be navigated like holding relationships, but do not have any lifetime management to them." In other words, a filtered view. Remember, everything is an object, and relationships produce a filtered view of those objects. Somewhere the OS is pooling these objects together. It always(!) assigns a unique ItemID (Guid) to every object it stores. Holding relationships(?) are saved filtered views, and Reference Relationships are just a quick view not saved. Any application that supports WinFS can then do tricks with any object the OS is aware of (rights allowing), much like with the file system today, except were talking serialized objects instead.

Somehow these relationships perform reference counting, and if the last relationship goes away, the object goes away. This would be like deleting the folder containing the last file. Everything is somewhere, so removing the last relationship kills the object (on the disk.)

The above document describes the effects of removal from the different relationship types on the object's reference counts. Very different from UNIX links, if only because it's so much more powerful, and it's linking serialized objects, not files.

"My brain hurts!" - Some Monty Python movie somewhere.

d/l-ing patches

The video files are large, ~50mb or more. Good stuff though. Real eye candy. WooHoo!