Thanks for the reply. I’m downloading the beta release and gonna have a play around with it.

Unit tests? what are those, never heard of them :P

Cheers!

Sun

LightSpeed combines traditional O/R Mapping with support for building .NET domain models (validation, data-binding etc.) It differs from other frameworks primarily in philosophy. Basically, convention over configuration (RoR style) so that if you are trying to solve the 95% case then you can move as quickly as possible. The framework is small and fast: a single 120KB dll that performs twice as fast as NHibernate (2MB worth of dlls) on our internal benchmarks. One of our internal mantras for LightSpeed is: “The utorrent of O/R Mapping.” :-) Another prime focus is usability – we have tried to make the API as intuitive as possible. It uses patterns from Domain-Driven Design such as Repository, Unit of Work and Specification.

The problem of changing the database schema underneath your data access layer occurs irrespective of whether you are using an O/RM. As you point out you can use code generation to generate your domain model classes off of your database schema and LightSpeed is good candidate for code generation. However, beware that code generation can have a significant negative impact on your day-to-day build process – i.e. It will slow you down.

The real solution to the problem is actually quite simple: Write unit tests. You do write tests don’t you? :-)

Cheers,

Andrew.

My limited understanding of LightSpeed, essentially it’s an O/RM technology… so apart from the plumbing code that most of the O/RM products out there are able to hide away, what is it that LightSpeed stands out comparing to others like Base4.net from alex.

Whenever I see table field names hardcoded in a class, my hands start to sweat. With my very limited experience with O/RMs, they are not very resilient db schema changes. Say if I went ahead and changed “ReferenceName” in the database directly. The above code wouldn’t be able to pick it up at compile time, could it? and I guess It will throw an exception or something sort in runtime if I’m to temper with the data in that field? From that assumption, I’ll have to change this hardcoded string to whatever I’ve renamed the field name to.

I am just thinking out loud here without doing much research on any solutions to this problem. Is it possible to design an O/RM in a way that, this data access layer/project that’s based on an O/RM, at compile time, is able to pick up the table name and fields from the respective metadata tables and code-gen these business enitity classes i.e. ConfigurationItem in this case? Then, if any existing business logic code that’s written against these business entity classes will fail during compile time rather than runtime which I would have had in your example?

What your describing sounds like an inheritance mapping scenario. Basically, when you want to map an inheritance structure to the database. There are three common patterns for implementing this: Single Table Inheritance, Class table inheritance and Concrete Table Inheritance. See here for a bit more detail on these patterns: http://www.martinfowler.com/eaaCatalog/

We currently only support Single Table Inheritance (mapping an inheritance hierarchy to a single table) because it is simple and has the best performance. Personally, I would be hesitant about using a multi-table strategy because I don’t believe it buys you much apart from perhaps saving a small amount of disk space.

With respect to associations, an Entity may have an arbitrary number of one-to-many or many-to-one associations, including self-referencing hierarchies. So a Job could have a collection of child jobs as well as a parent Job and an associated Customer.

LightSpeed has been in development for about 5 months and we are planning on releasing our first v1 release candidate this Friday.

Cheers,

Andrew.

Thanks for the quick reply. We have not yet looked into SQLite.

As for the two table scenario we have the following.

JobBaseData Table, made up of a JobID, JobState, and other fields.
JobSubClassData Table JobID (FK to Job Base ), and other subclass fields

The two tables linked together describe a Job in our System.

We may have say 2 different JobSubClass Tables, each one storing specific data for that particular JobType. ( we would create 2 objects JobType1 and JobType2 to represent the job data, both objects would derive from a Job Base object) .. Jobs are also Hierarchical, and a child job could have multiple parents ( Many To 1 Relationship ) ( not that a parent might be another job, or could be say a Customer or some other object )

Would this be possible in your system? How long has Lightspeed been in development?

Cheers

Cheers for taking a look. A couple of questions:

- Have you had a look at SQLite for your mobile scenario? The main reason we don’t support CE at this stage is due to it’s lack of support for batching which is required to use eager loaded associations. That’s not to say we can’t support it.

- Can you tell me a little bit about your two table scenario?

I would strongly advise against building your own solution :-) If LightSpeed doesn’t fit in this case I would recommend taking a look at Base4.Net from Alex James.

Cheers,

Andrew.

Nice product, not sure if it would do what we want, as we want to run on .net CF and full framework and use SqlCE and Sql 2005 as our associated Data Stores. Our objects would also need to gather data from at least 2 tables in the tables and i believe your product only does 1 -> 1 object -> table type mappings? Anyways i’m interested to know how long you have been working on the product, and what sort of resource and energy has gone into it? Trying to convince management that we are best to buy rather than build :) based on certain timeframes.

Cheers