Search for existing suggestions

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.

94 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Konstantin Tarkus shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Peter Buchmann commented  ·   ·  Flag as inappropriate

    In my latest project I did following:
    *) I took a third party modelling tool with support for UML class diagrams and modelling view models
    *) The tool has an interface that i could use to read the model and generate my desired code first class code, the code of the EF context and also the view model code using some T4 generators
    *) The class were generated as partial classes do I had one part that was generated and one part which I could use to extend the generated code
    *) The classes were generated to implement all necessary functionality out of the box (INotifyPropertyChanged in the model and in the view model, validations, error propagation from model to view model, and so on)
    *) The classes were generated to implement some base classes and interfaces
    *) This setup was ideal to implement my client app (Windows Forms with data binding to the generated view models and a custom event binding functionality). The forms only have a constructor as code behind
    *) I have a rate of over 90% generated code in my application

    I needed just this setup and 90% code generation grant a very high quality of the code. If I find a bug I can fix it in my code generators and get it fixed by regenerating code.

    In every other app scenario I would maybe need a different code generator. What code should the EF diagram designer generate for you?

    So my advice is: Think about doing the code generation by your own. Microsoft will never be able to generate the code you need. It paid off for me greatly.

  • Vahid Nasiri commented  ·   ·  Flag as inappropriate

    void ExportMappings(DbContext context, string edmxFile)
    var settings = new XmlWriterSettings { Indent = true };
    using (XmlWriter writer = XmlWriter.Create(edmxFile, settings))
    System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(context, writer);

    using (var db = new Sample06Context())
    ExportMappings(db, "mappings.edmx");

  • Gabriel commented  ·   ·  Flag as inappropriate

    I like the new Entity Framework code first approach. We're using EF6.1 right now.
    I think, howewer, that such a feature could enhance productivity further.
    In my view, it should combine information from the POCO classes themselves with all that is defined through FluentAPI and should also allow manipulating FluentAPI code through the designer.
    It should also be possible to let the designer do everything through FluentAPI so we can keep our POCOs clean from database specific annotations.

  • glthomas224 commented  ·   ·  Flag as inappropriate

    To get a good grasp of the relationships between classes in EF code first you have to open dozens and dozens of files and analyze the relationships. But with a diagram model you can you see at a glance what the bigger picture is.

    Does anyone from the Entity Framework Team know where this suggestion stands in the priority list or todo list. I personally feel that being able to seamlessly make changes to one's application from either the classes directly or the designer would be an extremely powerful asset. This is coming from a developer at a very large enterprise.

    I think if there was a great class designer that provided ALL of the same capability that Code First offered and more and more developers would lean towards just using the designer.

    Bring this tool to life Rowan Miller

  • glthomas224 commented  ·   ·  Flag as inappropriate

    For those out there that disagree with the need for such a tool. Then when it finally gets created, just don't use it. But there are compelling reasons to have a diagram model, one can very quickly at a glance see the relationships between tables. If the diagram gets large so be it, then it is up to the developer to lay out there model in the designer in a manner that is easy to read. For that matter why stop at a single 2 dimensional diagram. Perhaps it could be layered like sheets in an Excel Workbook, to help reduce clutter when data models get really large.

  • shimmy commented  ·   ·  Flag as inappropriate

    @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  ·   ·  Flag as inappropriate

    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 1

    4. 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?

  • Konstantin Tarkus commented  ·   ·  Flag as inappropriate

    @Ladislav, as of now the existing class diagram tool is missing core functionality which should be in POCO designer.

  • Ladislav Mrnka commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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).

  • Konstantin Tarkus commented  ·   ·  Flag as inappropriate

    Ragan Martin, I am not talking about tool which generates code, there is already one - Entity Framework Designer.

  • Ragan Martin commented  ·   ·  Flag as inappropriate

    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.


  • che commented  ·   ·  Flag as inappropriate

    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.

  • Konstantin Tarkus commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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).

  • teyde commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base