Alexnaldo wrote   Michael, Please, explain more about the data access layer. "This layer is not a physical layer but a dynamic self generating layer that will constantly read your definitions." -> Is it an ORM ? There will be an XML in place that allows to you to create your own component compositions, but if not used it will be using the database schema for now. In a later instance it also should be possible to have them created based on a webservice or XML. It is all about the definition and I don't care where the definition comes from . "By using the CodeDom classes will be generated and compiled on the fly, these objects will contain the knowledge of how to persist itself to the database and how to collect the data from the database." -> How to extend the schema ?  . Adjust the xml definition or the SQL schema (just SQL for now) -> How to query data ? the generated objects would have to know how to load themselves. I am working on this now! -> How to create calculated fields ? by defining them in the XML and have some function in place that can be injected in the CodeDom. -> How to validate data ? Validation will be done by the rules engine of WF.. but in the future there probably will be an IValidate interface so you could implement your own validation methods. "...drag and drop designer and let the designer be based on the newly generated classes" -> How the framework will handle this ? again using the CodeDom . the definition will be brought to a CodeDom generator to generate the dll for the screen. the designer would be instantiated through reflection of the generated objects as these represent you model. "...And even no matter what data provider we would have. SQL, Oracle, Access, XML, XSL, CSV or even a web service" -> How the framework will handle this ?   By introducing an IModel interface. the main screen only will know the interface.. How you implement that interface to collect the definition or collect the data is your choice. "..Raw SQL, Entity Framework or any other ORM platform all should be the same!" -> How the framework will handle this ? -> Can I uses EF and LLBLGen as ORM without changes ? The same answer as above. , Alexnaldo Santos

I do understand that is hard to get a grip on this when there is no  documentation yet. What I am trying to do is be as independent as possible. By having just a main screen and Interfaces I want to let the main app discover what is around him and let it be able to instantiate and use this through these interfaces. I hope to have a demo screen cast around this subject soon. but right now I am still working on the datalayer as this is one of the core elements of the environment.

In scaffolding objects you really don't need to have a complete object model of you data. But I will generate it because with nicely decorated classes I can use reflection to load and persist the objects to the database. The initial phase will just be around SQL. but eventually I want the Datalayer to be independent of where to get its data from or where to store the data. If you just have a CSV file that should be enough!

The only problem I have is that my head is so full of idea's that it is hard to keep focused on one particular issue and run of and work on a other part of the framework. 
 

The plan is to have this completely up and running in 2 months time. Of course this will be, as mentioned, all open source. Then I think we will have the opportunity to make even better implementations of the initial ideas. I hope I have given some answers and I can understand if you completely lost me.. but I guarantee this will work!

Hi Ryan,

Indeed you need to have more info but if you combine and substract all the required info you will end up the tabledefinition, its relations and columninfo.  How and where you will get these from is not really my concurn :-) as long as I can get the info through the interface.

The 1st phase is to build it up on a SQL backend and from their on I will define more interface so that you can exchange components in the chain as they are interface driven and have no references to each other.

Default I will keep in my implentation based on Subsonic. My favorite 'ORM' but in scaffolding you don't use the objectmodel as it is! you just need to have the info on what, where, how to store and collect.

But give me probably 2 more weeks and I will hopefully be able to do a 'long' cast on defining the database, building screens for scaffolding and executing these screens and interact with the datastore. This all is subjected to delay as I have my customers also.
And still am figuring everything out from scratch, but luckely have a good bag of experience to collect from !

But in the end you, the developer, will certainly be in charge on how and by what means the datastore is dealth with. Especcially with MEF and the interfaces you can take out one piece, adjust it to your requirements and replace the orginal part. and not just on one single place but you could have it on the complete chain from screen to the end of collecting and storing data. That is in my optic the way to go if you want to build a framework, because a framework should help you out instead of putting you in  restrain!!

So if anybody has some real good classes on reflection, object overloading, automapping routines,

It would be a to long piece of code but to give you an small idea of performance..
Creating the object tree for a

Contact
|____Address
          |______Country (Enum)
|____Gender (Enum)
|____RelatedContact -(Again a contact object)
 

This class structure is fully generated, and decorated with attributes and inherits a base class (for data stuff) this gets generated and compiled in just 110ms. If I would be able to generate the complete dataschema in objects in 500ms I am very happy as this is only at the first initial request! and perhaps we can let it load on a seperate thread while the screens are getting instanciated..

So you see, still a load of ideas but nothing real concrete yet.
 

I know NetTier, LLBLGen and many, many others ORM and I don't think a good idea create a new ORM...

After many years studing, using and creating (http://www.codeplex.com/nanomapper) ORM I must to say that Microsoft Entity Framework have good concepts that solved many of commons problems of ORM. IMHO EF is the best to integrate with VWG application.

,
Alexnaldo Santos