Entity Framework Feature 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.

138 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Konstantin TarkusKonstantin Tarkus shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    24 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • glthomas224glthomas224 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

      • glthomas224glthomas224 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.

      • shimmyshimmy 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.

      • herbertherbert 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 TarkusKonstantin 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 MrnkaLadislav 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 ZivkovicMilan 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 MrnkaLadislav 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).

      • Ragan MartinRagan 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.

        Regards

      • cheche 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 TarkusKonstantin 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.

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

      • teydeteyde 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.

      • Daniel DiVitaDaniel DiVita commented  ·   ·  Flag as inappropriate

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

        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.

      ← Previous 1

      Feedback and Knowledge Base