POCO support should not be a feature, it should be builtin. It has always been possible with CodeFluent Entities because the classes the product generates derive from System.Object (the default mode), or from any class you want, not from some framework class that you can’t change. Note also we don’t use Reflection mechanisms. This is fairly easy to do, just add the baseTypeName attribute, and specify the base class full name, like this :
For those of you wondering what really is in the product, here is a graph generated using the cool Visual NDepend tool, for a total of more than 110000 Lines of Code (metric defined by NDepend). What’s interesting is to categorize all these nice but hardly visible gray boxes. This is what we have done in the next image.
This is the same box, but with CodeFluent Entities features here arranged in 4 big categories: Import (reusing existing model or databases, and avoid loosing existing investments), Modeling (including the soon-to-come visual tools), Production (the real meat!) and Runtime support. As you can see, Modeling is still quite big, especially the in-memory model (the biggest box of all) built after parsing time. Runtime support has grown recently due to the recent SharePoint (WSS/MOSS) and Silverlight 2 support.
CodeFluent Entities R&D Team