I am spending some time regularly on radzen and i am beginning to like it. How ever i have to admit that i am not comfortable with certain architectural aspects of the generated code.
We typically have a service file for each page, and that service file implements a service interface, whereas radzen has just one service file for all entities/data.
We inject the service interface into components, rather than the service itself (thereby more decoupled) This is also useful when we unit test the components... we can supply mock implementations of the interfaces
3 .We group pages together in a folder, Say Employees folder, Customer folder and so on, radzen puts all at root level (/Pages)
We typically can have these pages/components derive from a parent component of ours, which will have some frequently used properties that can be inherited
We use code first migrations heavily
There are many such fine tuning we require, so my point is this:
Is it a good idea to use radzen ONLY to generate CRUD UI + CRUD code + Auth Code (possibly in a separate project from our production project) and then copy paste that code into our main project, rather than using a single project which is difficult to customize as per our needs?
Indeed Radzen is opinionated about certain things. The generated code is the simplest thing that works. This comes at the price of not allowing the developer to have full control over the generated code.
It is up to you to use Radzen in the best way possible (or not use it if you need to have full control over the source code).
I also agree with you on "generated code is the simplest thing that works"
Let me take a 'blended' approach of having two different projects, one for production and other for Radzen code generation... i ll post my observations after a few days... might just help someone with the same question...
Having written several Enterprise code generators, here are my thoughts:
We typically have a service file for each page, and that service file implements a service interface, whereas radzen has just one service file for all entities/data.
From an organizational perspective, that would drive me crazy with so many service files in a massive Enterprise app. I would prefer there be one file for each "area" or "group." However that is defined. There is not right or wrong... It is simply a personal preference.
We inject the service interface into components, rather than the service itself (thereby more decoupled) This is also useful when we unit test the components... we can supply mock implementations of the interfaces.
This would be nice to see in Radzen.
3 .We group pages together in a folder, Say Employees folder, Customer folder and so on, radzen puts all at root level (/Pages)
Organizationally, this would be awesome in Radzen... It is straightforward for Radzen users of all levels.
We use code first migrations heavily
This is something I "built into" my code generators in the past. It would be very helpful if Radzen generated migrations as needed when one clicks the "Infer Schema" button.
As one who has paid for a Pro license, I'd still like to see "Out of the Box" Security implemented before anything else.
Have you guys used code first with radzen, how was your experience? Did you use a separate console based project which manages the code first migration?
