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
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.