This project is read-only.

Mindscape Lightspeed

Apr 18, 2009 at 9:01 AM
how do you compare with Lightspeed ?

Apr 19, 2009 at 4:12 AM
Edited Apr 19, 2009 at 11:41 AM

Hi dracnet, 

I'm not an expert in Mindscape Lightspeed, but I've seen many differences so far:

* The most obvious one is that we are LGPL, free of any cost even for companies, while Lightspeed is a product. 

*Also, the philosophy is different. They are flexible, allowing Domain Driven (entities first) or drag and drop tables (DB first). We are not. We are focuses on domain driven (entities first) only. 

* They encourage Unit Of Work pattern, while we differentiate from ObjectCache and Transaction (no DataContext).

* When there's communication,we encourage sending entities to the client application, while Lighspeed entities have to be attached to a data context, so they are confined to theserver and DTO have to be created. 

* Also, we encourage the entities to be written by hand, in order to make it easy to add validation,while they use a designer.

* Finally, for us the ORM is maybe the more important step, but just the beginning to create a framework for building LOB applications. We also provide facilities for WPF interfaces, and working on ASP.Net MVC, our aim is to provide application modules that can be easily integrated in any application that uses Signum Framework. 

I've found MindScape much closer to LINQ to SQL or Entity Framework than to Signum Framework. IMO Mindscape is a good choice if you planning to use LINQ with a DBMS different to SQL Server. We are playing another game.

Thanks for your question :)

Apr 19, 2009 at 7:42 AM
Edited Apr 19, 2009 at 7:49 AM
Many thanks for your answer
just FYI:

Apr 19, 2009 at 12:28 PM
Edited Apr 19, 2009 at 12:46 PM

If you remove the bias that each of us have on his product, we have said something similar. Let's try to make a list in witch both could agree:

- Mindscape costs money, Signum Framework is free of charge.
- Mindscape is mature, Signum Framework is fairly new (just like Java and C#, hehe)
- They support more Databases, we are *SQLServer only.
- The LINQ provider is a fairly complex piece of code. We are proud of our provider, would be cool that John Daniels passes the Frans Bouma test 
- They provide a cool designer, we prefer C# code to be the only model** (you can use VS class designer anyway)
- They are an ORM, we are a framework around and ORM (Signum.Utilities, Windows, Services and the upcoming Signum.Web)
- Their entities are confined to the server, while our entities can be easily sent to the client.

* It wouldn't be that hard to add support to other databases, especially since we have no designer. However, I'm completely sure that it will end up in an unstable platform for building applications. Imagine trying to use a Task module that was originally written for MySQL server in an SQLS application, probably there will be subtle differences in the way a LINQ queries work, or different performance considerations... our bet is to provide the framework where applications modules can be easily composed, multiple databases would be like having LEGO with rubber, plastic and wooden pieces.

* We don't have a designer, instead we have focus on making entities as sorts and consistent as possible (using Attributes, Set method, Lazy<T> and MList<T>) so that a few snippets are enough to be productive. Designers are cool because they abstract away some information, so you can understand a class hierarchy better, but there's nothing as expressive and sort as pure code if you want to provide all the information: you can make complex validations, vary the getter and the setter...see if Validation and DB Constrains are at sync. Also, I don't know how they solve the problems but MS Designers are impossible to manage when you reach a certain amount of entities (+30) since all have to be in the same surface, and are impossible to merge if you planning to create resusable application modules. We are focused on CRM / ERP that have many entities.
For this reasons, we are not planning to support any of this two features anytime soon. Instead, apart from Signum.Web, our roadmap is to continue creating a solid basement for creating app modules. There are many concrete examples in the next version:
- Events before/after saving, retrieving and deleting an entity. (To enable centralized logging and authorization, and custom caches invalidation...)
- An event infrastructure for Synchronizing, and Generating the DB, and initializing the application, so plug-in modules is as easy as possible.
- Renames in synchronizing the DB schema
- Important visual changes in Signum.Windows.

They won in response time by a few hours. What can I say… :)

Kind Regards,

Apr 20, 2009 at 7:44 AM
Hi Guys,

Just a few additional points:

  • We only added the designer in version 2 of LightSpeed. The designer is very much built by folks who don't really like designers meaning that we've gone out of our way to ensure that it works really well for people who don't like designers either. This means if you want to add custom attributes you can directly from the designer. Want to put some more expressive logic in a getter or setter? Just set the property to not be codegened and then put the code in a partial class. Want to add custom namespaces for your custom attributes - not a problem. The templates are all NVelocity based and you can alter them if desired. Having said all this, you absolutely do not have to use the designer and the help documentation still has a very detailed getting started guide if you prefer to write your own entities. We also have a command line generation tool if you're not big on writing it all but don't want a designer either :-)
  • I'm sure you didn't mean it to sound this way Olmo but our handling of multiple databases hasn't resulted in LightSpeed being an unstable platform. A heap of effort has had to be spent working on making this area work really well but sometimes challenges do arise simply from what various database engines support. SQL Server is by far our most popular database that is used with LightSpeed so it's probably a good idea to keep focus on what most of the market is using. Folks who want to move to a new database just need to setup the structure in the new database and set two configuration keys - the connection string and the database type - and they're good to go. LightSpeed 3.0 should make setting up the new database very trivial.
  • The large number of items on the surface is an issue in very large models using the Visual Studio integration tools (which are both great and a challenge at the same time). We're working hard on a solution to this for a future version of LightSpeed.
  • The LightSpeed designer was built from the ground up to do model first OR database first development. You can push changes from the designer to the database or pick them up from the database with a simple right click update action. We call this feature full scheme round tripping and allows very fast initial development of a domain model. The designer also supports Single Table and Concrete Table inheritance (relating back to the earlier point of not liking designers - it's often because we found them to be more marketing fluff than useful and hence wanted to ensure that what we built delivered the full feature set of LightSpeed rather than fall prey to the demo-ware nature of many design surfaces).  This includes rename support, adding tables/enitities, adding and removing fields, adding and removing foreign keys etc. LightSpeed 3.0 will also generate automatic migration scripts of these changes.
  • If anyone is interested, the general difference between LightSpeed and Signum in terms of managing objects is that we use the Unit Of Work design pattern while the Signum one appears to more closely reflect the Active Record pattern.
  • The LightSpeed models already include the before/after saving life cycle events.
  • LightSpeed 3.0 (due out mid year) will have client side entity support - it's been a big request recently so we're commited to making that happen.
>> They won in response time by a few hours. What can I say… :)

You could say I need to get a life and not be online working on Mindscape stuff so late on a Saturday night :-)

Going full circle to some of the points raised here, I really don't see these products as competing heavily with each other. The Signum framework guidence is great for people wanting to start building applications quickly and that's always a good thing. We have some plans around this area but it's too early to go into what we're doing - we're currently focused 100% on delivering LightSpeed 3.0 as we believe it's a massive step up in terms of ease of use, flexibility and power.

Happy to discuss any other points.

John-Daniel Trask
Apr 20, 2009 at 9:30 AM
Hi John Daniel!

Thank you for your response, and don't worry. I don't have a live either :)

About the designer, How it reflects changes in code? Does it have an external XML? If it does, it contains the layout or also the enities itself in a Xml manner? I'll take a look tonight but it looks you have a quite good designer :) I still concerned about big designer surfaces, and scenarios where yo uhave to merge surfaces in different assemblies (big issue for Signum Framework, not for Lightspeed)

We are mainly focused in composable applications, having an stable platform is more important in our scenario. Otherwise if you build a module you will have to test it agains any supported database. I don't think it's worth given that SQL Server is the facto standard in .Net.

Not sure about Signum Framework being and Active Record ORM. Active Record sounds DB-Driven while Signum Framework is radically Entity-Driven.

Good to have an honest chat with other ORM developers :)

May 18, 2009 at 2:46 AM

If I may chime in on this little discussion.

As a systems designer myself I can appreciate the work that goes into both of your systems however when businesses pick and choose these types of frameworks, flexibility is of the top most priorities. Often enough flexibility and tooling surpasses priority of code-elegance.

Real businesses and real projects are often a mix mash of languages, technologies and old versus new components.

There's 2 things I hear with rigid sentances being mentioned often in Signum Framework and that is "we are only domain driven" and "we only support SQL server".

Unfortunately for most businesses, these 2 factors pretty much decide it for us. No matter how awesome the framework is, serious architects just don't corner themselves like this. Choosing a system like this which would mean overhauling significant pieces if we ever had to bring on Oracle or MySQL.

Not to mention the inability to hook into existing systems.

When we scope out enterprise systems, flexibility is top. We absolutely NEVER choose a technology that binds us to one specific thing. NHibernate supports multiple DB's, SubSonic does and even the Entity Framework supports many DB's.

If you want larger projects to adopt this thing, the Signum.Web and Winforms etc stuff is the least of what people are looking for. Those are all useful, however the 2 options mentioned above are deal breakers that will discourage people from ever getting to use those.

It's nice to have domain driven in this framework, but having it as the only option is a serious problem.

Although the development of this framework may be awesome, it'll be picked up by people who think or don't realize the rigidness they are choosing. I hope this changes in the future.

As far as designers go. Microsoft has proved code generation to be a very very valuable tool. There's no reason all your classes you show us in your videos can't be generated off a DB. A designer surface isn't so much required. Flexibility is required. Perhaps some simple tools, but you don't need anything like a Entity Designer.

If this framework really wants to steal users from NHibernate and Entity Framework, you need to be more flexible:

1. Support multiple databases.
2. No designer needed, but allow mappings between property names and columns, tables etc. For example an old legacy database, but we want our C# apis to be clean, so Node is the class name, Nodes is the collection name, Nodes is the table name. You might want to rename properties as well. People don't need a designer, they need a customization tool. Not a mapper like Hibernate, just an override for customization mappings, 90% of it will be as-is.

Microsoft is investing heavily into T4 templates these days but some of it is kind of half done work that you have to do manually etc. Editting a T4 template to adjust your property name mapping to a column is a bit of overkill, however the tools behind the scene can use them, that is fine. T4 templates should be used for hardcore templating needs.

That's the bulk of it right there.

Like I said, systems vary, real companies have legacy products, with new projects coming on board all the time. Very few projects get to start completely from the ground up.

May 20, 2009 at 2:08 PM
Edited May 20, 2009 at 2:09 PM


Hi Synced,

We know that there are plenty of ORM out there that support different DBMS, and a few of them (NH and EF) also support multi paradigm. We are also sure that your opinion is the opinion of most of the people that has rejected Signum Framework, but... why create just another flexible ORM? Especially now that Microsoft is investing lots of money on EF?

Our aim, and the reason we build SF four ourselves in the first place, is because an ORM that can be based on solid foundations on the entity model can reach levels of productivity and re-utilization that are just not possible with the flexible ones. The simplicity of Lazy<T>, or how fast you can create (and modify!) the UI thanks to the EntityControls is an example. We will see more examples in the next version.

It would be really easy to add a [ColumnName("MyColumn")] attribute over fields, but we still need EVERY table to have an Id (int32) and ToStr, and we need MList to be created just the way they are, so it will be just a pretended flexibility.

We are not completely against code generation, we just think that entities are the most sensible part of your application, and using code generation for it makes some scenarios more complicated (like adding validation).

Also, since Signum Framework is free, we are not making money if the big companies use it to solve their specific problems in their specific DB schema. Instead we are focused on modularity and composability so that other developers using Signum Framework can create business modules that can be reused by anywhere else, including us, enforcing community effect. Maybe is a utopia, but the dream just won't work in more flexible scenarios.

So, in some sense we are competing with NH or EF, but we want to be an application framework, not an ORM, so we are also competing with Dynamics or SAP.

There's no doubt that a 4x4 Pickup is more flexible than a urban car, but there's still lot of room for cars that only work over asphalt roads that are simpler, faster and take less oil. And you can also use a pickup when you to the mountain!

Thank you for your feedback.



May 22, 2009 at 2:28 AM

I understand your point of view but unfortunately very few projects get to start from the ground up so you are working on tons of value added functionality on top that is usable by a very small audience.

All of those are good ideas, however without a flexible base, it all goes to waste where you could be reaching a far greater audience.

I'm not trying to critisize but I hate to see projects not reach their potential because so many people just "can't" use it. It's unfortunate.

Nov 19, 2009 at 4:15 PM


Coming in a little late on the discussion.

I have a new project that I am starting on and have been searching for some relatively easy way to get going on the analysis that I need to do. Unfortunately, my model has a dozen classes interacting in a multi-dimensional way including recursion. So, a standard DB like Access was eliminated immediately. I am just starting to learn C# and Visual Studio. A couple years ago, I tried OOP with VB5: what a mess I ended up with.

Anyway, I was looking at lots of ORMs and frameworks and getting frustrated. Finally, I sat myself down and said "What do I want exactly in a programming language?" My answer was "Lego". I want small components with boringly identical connections. Then I searched for Framework and Lego and discovered Signum Framework. I am now trying it out. It looks like exactly what I want. I definitely want my model to drive my DB and not the other way around.

So, thanks from one member of your "small audience".

Nov 29, 2009 at 8:52 AM

Thank you for your support Hezek1ah.

Signum Framework is growing a lot under the covers and I hope we will have some time to upload it and show all the great stuff that it does now. We have build about 20 different bussines modules already (entities + logic + wpf windows) and they merge smoothly in the solution and in the database, Just like lego bricks.

Stay in touch, and tell me if you have some problem using SF.

PD: If you are starting with C# now, I will recomend to read C# in Depth ( from Jon Skeet ( to have a good understanding of the language. Specifically Lambda Expressions.