This project is read-only.

Extending the generator

Aug 11, 2011 at 7:18 AM
Edited Aug 11, 2011 at 7:23 AM

It's just an idea, I know the focus of NHydrate is DAL, but ... If I want to extend the generator to generate some CRUD UI, like ASP.NET Dynamic Data Entities web application template... Is it possible? I'm targeting WPF/Silverlight. I would like to generate some views/viewmodels, following the MVVM pattern, with CRUD forms/datagrids based on a model/metadata. It seems that extending nHydrate to do this is a good idea... What about this?

My idea is that the wsgen model could have additional properties like "generate form = true", "generate list = true", and mark the fields that will be visible/editable, etc etc etc. And of course, the generated forms binding to data from the DAL Layer.

Aug 12, 2011 at 1:33 AM

Yes you can build your own generator and it will show up in the generate dialog. There is an article on this here.

The easist thing to do is download the source from Codeplex and look at how we implement generators. You can build one the exact same way. We just implement a particular interface and nHydrate picks up all DLL library files in the install folder and loads them.

Aug 12, 2011 at 7:55 AM

Thanks for the answer. I read the article and just started to create a project/DLL based on DAL generator (learning by example). My goal is generate some screens/views based on fields of the wsgen model and I'm very excited. Wish me luck! If I achieve what I'm expecting, I will let you know here.

Aug 15, 2011 at 4:07 PM

My custom generator is working as I expected. My WPF CRUD forms (views and viewmodels) are generated based on tables of the nHydrate model. My goal is EFDAL.

I am inspecting the EFDAL generated code, and I need to access data in a repository approach. What`s the recommendation for implementing a generic repository based on EFDAL taking advantage of the generated code of nhydrate?

Aug 16, 2011 at 11:35 AM

You need to look for articles about wrapping entity framework in a repository. One Example:

The primary reasons for the repository pattern are Testability, Abstraction and Dependency Injection.

Depending on your needs you may consider ignoring the repository pattern and exposing the EFDAL through WCF Data Services.