Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to gen all models, and save the settings in a seperate file #189

Open
7 tasks
fasteddys opened this issue Feb 7, 2023 · 3 comments
Open
7 tasks

How to gen all models, and save the settings in a seperate file #189

fasteddys opened this issue Feb 7, 2023 · 3 comments

Comments

@fasteddys
Copy link

Hello this is very nice, I love that you can generate from the entities/models that perfect sweet spot for developers in dot net.
It would be nice if we can map/save those settings easily in a separate file, so that the models can be updated with new versions of cloudy.

Q: I understand you are doing this with models, how are view models handled is it the same?
For e.g. if we had a customer model with cloudy annotations, then had invoice that's composed of order+customer, then annotations from the customer would collide with the invoice model, right??

Some samples references

Suggestions:
A visual RAD tool to map and create the entities in cloudy would RAPIDLY SPEED UP ADOPTION & Code gen

@bjorn-ali-goransson
Copy link
Contributor

Hello @fasteddys

@bjorn-ali-goransson
Copy link
Contributor

I apologize for not responding sooner, we didn't expect anyone to express interest just yet 👀 you are most welcome though!

Interesting thoughts.

First of all, we generally don't support the idea of code generation. Defining application entities is an art, and should not be done by a robot.

Additionally, even for a moderately complex application, defining entities should at most take 1-2 hours and most development time will be spent elsewhere.

Secondly, I would suggest leveraging EF Core (keep in mind Cloudy is not compatible with EF 6.0 as per your diagram) to configure any stored procedures you need.

Most of the Data Access Layers and Service Layers in a multi-tiered architecture are actually not necessary for many standard applications, you should be able to get by with a single EF Context, and maybe a utility class on top of that for complex queries.

Then, Cloudy should be able to take care of the rest of the business rules while keeping everything (and especially your model) as simple as possible.

I would be delighted to have a call with you and discuss your ideas and thoughts, we could even prepare a proof of concept for you with best practices (free of charge of course). NDA would be possible to discuss.

Attached is a naive diagram of what should be possible with Cloudy. We do have some gaps with regards to implementing business rules though.

image

@fasteddys
Copy link
Author

hi bump 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants