pilotboba wrote:

I'm not sure if you ever looked at a product (now defunct) that was moved to SourceForge called ORM.Net.

Yes, I've looked at ORM.NET when I started with LLBLGen Pro. It's always good to peek at the neighbours how they manage to make their lawn look so green

I didn't like some of the stuff they did. For example, there entities are just wrappers around datasets.

But for fetch path and predicates (they called it criteria) they used enumerations. So, there was a join path enumeration that you used to specify fields.

yes, it was very elegant. The downside to me was that it generated a lot of code when the project became bigger, and had the downside that with the enums you still have to produce the actual relation object, which could only be done in the generated code, so it would bring me not that much.

So you could do:

dm.QueryCriteria.And(JoinPath.Student.Columns.FirstName, "Tom", MatchType.Exact)

dm is their datamanger, similar to NHibernate session.

Or:

dm.QueryCriteria.And(JoinPath.Student.Enrollment.Schedule.Course.Columns.ClassName,"Algorithms 100",MatchType.Exact)

You could even string them together with Or / And, whatever:

dm.QueryCriteria.And(JoinPath.Student.Columns.FirstName, "Bill", MatchType.Exact).Or(JoinPath.Student.Columns.LastName, "Clinton", MatchType.Exact)

As you can see, there was an overload with a third parameter for MatchType.

The also had a single FetchPath enumeration that also drilled through all the relations to define your FetchPaths:

student = dm.GetStudent(FetchPath.Student.Enrollment.Schedule.All);

I really liked their method, it was easy to understand and figure out. At least to me. I also think the code read very closely to the way the SQL might read.

I think the basic Idea here is that there were to Enumerations, FetchPath and JoinPath that let you define the Entity and Column (field) very simply.

Their enums were the single thing I liked about their solution, to specify paths. But don't underestimate the code required to make this work. It was a lot of code to generate (if I remember correctly, the last time I looked at it was in early 2003) and I liked more the EntityRelation object approach, which gave you all the flexibility you wanted for not a lot of extra code.

What you specify as good as in readable, is that they specify the joins with the predicates (field operator value/field etc.). LLBLGen Pro separates them, which makes it a bit harder at first: you have to specify relations and predicates, and they seem to be disconnected at first (which was addressed in adapter, but selfservicing still has disconnected relation collections and predicate expressions).

There's no 'query' object, you have a set of objects which make up your arguments for the method which will perform the action. IMHO that's more logical, when you look at other methods you'd call in the .NET framework for example: you there too specify arguments of the method, you don't group them in an argument bag object, passed in.

Though it's a problem that's hard to solve IMHO. SQL is set oriented, and C#/VB.NET and .NET are OO / procedural oriented, not set oriented per se. So to make C#/VB.NET and a framework represent itself to consume SQL-esk or better: set-oriented operations, a translation has to be made, and it's always 'weird' when you know/look at the SQL.

Cadmium wrote:

louthy wrote:

Out of interest how long until the new system is available? If it's going to take a while and there's enough interest, I'll make my source-code and util app available to the group.

Paul

I'm definatly interested in seeing your way of doing things. I've never really considered operator overloading and have been writting the predicate statements by hand and just simplify my bl methods for easy of use. If I could making writting those easier too, that would be awesome

Here you go: http://www.level83.com/ow.asp?LlblGenPro

I remember another reason why I didn't go the ORM.NET's enum route: multiple relations with the same entity. Customer has 2 relations (1:1) with address. how to distinguish between them? With these enums it's hard IMHO.