When J2EE came around, the notion of a container and managed objects / entities came into the fray, but those had such a high cost associated with them, that the Java community rebelled and now mainly advocates the Plain Old Java Objects. The .NET community has taken the same approach recently, with POCO or PONO being the term used.
This post is driven by my experiences with several of Microsoft's tools that tend to focus on "No Code Required". WebForms' 2.0 had a huge marketing focus on that, and MS CRM is being sold with the premise that you can extend it with just a GUI, so does many others tools from Microsoft (SSIS comes to mind).
I outlined the problems that I see with this model here, so I will not repeat it here, but I want to focus on code vs. GUI right now. I am aware of only a single such tool that provide a really good service, and that is the WinForms designer, and even that fails occasionally.
But what really gets me is the CRM's style of designers, where the customization is locked tight somewhere, where I cannot access it in any meaningful way.
Given the chance, I would define customization with code, probably a DSL, and probably something like this:
entity MyCustomerCustomer: CustomerNumber as int [Length(255)] Name as string Email as Email screen MainView, for: MyCustomerCustomer: tab "Customer Properties": Display Name Display Email Display CustomerNumber, readonly
Hm, I seem to getting back to DSL no matter which way I go recently.