Class diagram for Code-First POCO classes
Need a new type of ClassDiagram tool for Code-First POCO classes which should be similar to Entity Designer, capable of showing relationships, keys, db schema related meta data etc.
Konstantin Tarkus
shared this idea
22 comments
-
Mike
commented
Ya.
-
shimmy
commented
Meanwhile checkout this post: http://goo.gl/5vkQM
-
shimmy
commented
@Ladislav, I strongly disagree with you.
I think this is very compelling and even obvious.
Class designer doesn't target the features EF has to provide (Key? MaxValue, FixedValue etc.), nor doesn't it target relationships in such an easy way as the EF designer does.
Besides, "limitation" is why we have partial classes, all the rest the designer doesn't target, is implemented in the partial classes. This is clear as the sun. -
herbert
commented
I run several tests with my students:
1) is it possible to create a recipe (type of "It-just-works") how to extend an existing object graph without persistance by applying code first?
Julie Lermans EF CF book only covers navigation properties, it does not cover the details of OO inheritance. For example having an abstract base class, code first does *not* by default create TPH unless specified using the fluentAPI.
2) What is necessary to analyze an existing code first app?
- the Class diagram from VS
- the ERM diagram from SQL Mgmt studio
- the source files with annotations and fluentAPI calls.
3) How should the new diagram look like?
- it should allow to switch the DB info on/off
- it should distinguish what is defined by the developer and what is deducted by Code First conventions
- it should highlight what is a PK-FK relation and what is a navigation property
- it should display which names are changed: pluralization, mapping instructions
- this includes the requirement for SQL Server relations to carry additional metadata about inheritance (in case it is used for it)
- it could offer a preview mode: "this is the DB you get, if you run the app now".The students I watched use code first in an iterative loop:
Step 1: tweak the code using fluentAPI
Step 2: it DB is not what you want, repeat step 14. which leads to my ultimate goal: Is it possible to create a converter tool, that enhances an existing object graph by code first, thus automatically adding a persistance layer?
-
@Ladislav, as of now the existing class diagram tool is missing core functionality which should be in POCO designer.
-
Ladislav Mrnka
commented
Milan: POCO designer = class diagram supported in all versions of VS. Also I don't agree with your mentioned strength of visual modeling. Visual modeling has its limitation and the good code is the best description of model.
-
Milan Zivkovic
commented
I vote for POCO Designer. This discussion leads to story of modelling. We are discussing here about visual model (POCO designer) and textual model (code). Visual modeling is the strength of human brain (1 bitmap = 1 megaword). So, it's logical for me to use Visual Modeling Tools. It's even OK if someone prefer to express himself with textual models, but team work for the brevity of communication requires visual models. POCO Designer won't defeat idea of Code First. It's should be possible to work with POCO without idea of Designer's existence. I think that the point for POCO designer supporters is combination of POCO designer, POCO classes independancy (and extensibility) and great DbContext API. We don't have that with the existing EF designer. Even more it would be perfect to have POCO designer with 2 way synchronization - roundtrip engeneering (model-to-code, code-to-model) of entities, relationships and annotations.
-
Ladislav Mrnka
commented
This is now available in Entity Framework Power Tools CTP1. There is possibility to create read only EDMX diagram from your code first model (your current mapping configuration).
-
Ragan Martin, I am not talking about tool which generates code, there is already one - Entity Framework Designer.
-
Ragan Martin
commented
Code First does not really involve diagrams, I really think if you're an experimented developer you wouldn't want to spend time reviewing ugly code generated from diagraming tools or T4 templates to generate something that's simple like POCO classes. I never use diagram tools from VS and whenever I've tried to use them they only complicated the work.
Regards
-
che
commented
I have to agree with Koistya, although I want more than just a diagram. I would like the tool to show me how my classes match or differ from the (or any) database. I find that code first works great for the initial phases but over time it's hard to keep the DB and the code in sync.
-
Lucas, I think you don't get it.. I need a class diagram tool which could visually represent POCO classes, otherwise how are you going to show your model to other team members? POCO Class Diagram allows to view all the classes on one display, effectively discuss them with team members and tweak if needed.
-
Lucas
commented
I agree with teyde. If you want a designer, code-first might not be the right way to go. You can create your POCO classes with the EDMX designer (model-first).
-
Chris Schear
commented
Great suggestion!
-
teyde
commented
For once, the hibernate / NHibernate guys doesn't seem to miss it. Then I don't believe non-coders get much value from it. Non-coders would typically care about project value, and that's not expressed very well with a designer diagram. Less so with many classes. But what I fail to understand is why do you want a designer with Code First? Code First is all about code. The idea is to provide an environment where the business classes are totally void of any database information. The mapping happens by conventions or in separate mapping classes. I don't think a designer in this scenario will ever happen. It's either impractical to implement or at direct odds with the concept of Code First.
-
Daniel DiVita
commented
How does that defeat the purpose? I know what your trying to say, but visually it may help non-coders to understand the model better. Also, even as a coder I think it would be invaluable.
-
Daniel DiVita
commented
How does that defeat the purpose? I know what your trying to say, but visually it may help non-coders to understand the model better. Also, even as a coder I think it would be invaluable.
-
Jan
commented
It will be grate to have visual disigner for POCO EF
-
teyde, I don't create classes in ClassDiagram either. But when you need to tweek something in existing classes and have a full picture of all domain classes in one place, on one screen, that's where ClassDiagram tool flourishes. It's just not suitable for working with db entity classes .. just yet, unfortunately.
I believe that code Code-First development approach shouldn't prevent you from using powerful development tools. Otherwise people would write their code in notepad still. Technologies evolve, development tools are matter. The more advanced tools you use, the more job you can done in a shorter period of time, the more advanced systems you can engineer. That’s all about productivity.
I think that Visual Studio team should release new version of ClassDiagram tool which would be suitable for working with entity classes by reading metadata from data annotation attributes. Eventually it could behave more like Entity Framework Designer, being able to show relationships between entity classes, keys, validation rules etc.
-
teyde
commented
I don't design code that way, so, no I haven't used the ClassDiagram feature that much. I also don't use visual designers to create code as they don't scale. Add more than a handful of entities and the diagram starts to clutter. But what I initially meant was, if you prefer to design code by a designer, I really don't think Code First is the proper choice.
