Hello

I have entities which I want to generate DTOs for. I have an AuditLog class which has a reference to Users. How do I stop Users property from pointing to class AuditLogTypes.Users and rather point straight to the Users class. I can do it manually after each generation but I have 30+ entities to change each time.

public partial class AuditLog
    {
        /// <summary>Gets or sets the AuditLogId field. Derived from Entity Model Field 'AuditLog.AuditLogId'</summary>
        [DataMember]
        public System.Int32 AuditLogId { get; set; }
        /// <summary>Gets or sets the AuditTypeId field. Derived from Entity Model Field 'AuditLog.AuditTypeId (FK)'</summary>
        [DataMember]
        public System.Int32 AuditTypeId { get; set; }
        /// <summary>Gets or sets the EntryDate field. Derived from Entity Model Field 'AuditLog.EntryDate'</summary>
        [DataMember]
        public System.DateTime EntryDate { get; set; }
        /// <summary>Gets or sets the Id field. Derived from Entity Model Field 'AuditLog.Id'</summary>
        [DataMember]
        public Nullable<System.Int32> Id { get; set; }
        /// <summary>Gets or sets the Machine field. Derived from Entity Model Field 'AuditLog.Machine'</summary>
        [DataMember]
        public System.String Machine { get; set; }
        /// <summary>Gets or sets the Users field. </summary>
        [DataMember]
        public AuditLogTypes.Users Users { get; set; }
        /// <summary>Gets or sets the UsersId field. Derived from Entity Model Field 'AuditLog.UsersId (FK)'</summary>
        [DataMember]
        public System.Int32 UsersId { get; set; }
    }

Should appear like this

public partial class AuditLog
    {
        /// <summary>Gets or sets the AuditLogId field. Derived from Entity Model Field 'AuditLog.AuditLogId'</summary>
        [DataMember]
        public System.Int32 AuditLogId { get; set; }
        /// <summary>Gets or sets the AuditTypeId field. Derived from Entity Model Field 'AuditLog.AuditTypeId (FK)'</summary>
        [DataMember]
        public System.Int32 AuditTypeId { get; set; }
        /// <summary>Gets or sets the EntryDate field. Derived from Entity Model Field 'AuditLog.EntryDate'</summary>
        [DataMember]
        public System.DateTime EntryDate { get; set; }
        /// <summary>Gets or sets the Id field. Derived from Entity Model Field 'AuditLog.Id'</summary>
        [DataMember]
        public Nullable<System.Int32> Id { get; set; }
        /// <summary>Gets or sets the Machine field. Derived from Entity Model Field 'AuditLog.Machine'</summary>
        [DataMember]
        public System.String Machine { get; set; }
        /// <summary>Gets or sets the Users field. </summary>
        [DataMember]
        public Users Users { get; set; }
        /// <summary>Gets or sets the UsersId field. Derived from Entity Model Field 'AuditLog.UsersId (FK)'</summary>
        [DataMember]
        public System.Int32 UsersId { get; set; }
    }

Is this with v5? Or with a lower version and your own templates?

V5 thanks

smurrell wrote:

V5 thanks

In this particular case it might be possible, but in a lot of cases type problems occur. E.g. if you also have another DTO which also has a 'Users' type, you'll get a type clash. As the nested types are unique for each root derived element, they're defined within that namespace. This requires that you have to specify some more namespaces in your own code but it's otherwise likely going to be a problem elsewhere, hence the nested namespace.

I want it to point to that users type as all the stuff is related. No need to create multiple classes of type Users for example when I have defined one already in db and then it pulls through to dto

smurrell wrote:

I want it to point to that users type as all the stuff is related. No need to create multiple classes of type Users for example when I have defined one already in db and then it pulls through to dto

No, that's not how it works. If there are multiple entities A and B having a relationship with the entity C, then 'C' will end up in both the DTO ADto and BDto, but they're not the same: you can have different fields in the CDto related to ADto as you have in the CDto related to BDto. ADto owns the elements it relates to, so its own CDto. BDto owns its own elements too, so also its own CDto. You might decide to add additional related elements to BDto.CDto, which doesn't affect ADto.CDto, or denormalize fields from ADto.CDto into ADto, which doesn't affect BDto.CDto.

Due to this flexibility, the types are redefined, because they are different types. It's not a simple 1:1 reflection of the entity model, it's a derived model, you can change things, e.g. denormalize fields so they're no longer in e.g. 'Customer' but now part of the related element 'Order'.

I am using BreezeJS with it. Will it pull out the data from the database should Breeze ask for the additional data from the type?

I am thinking maybe I need to switch to use EF as I did in previous Breeze project. I just prefer using LLBLGen as I find the entire product easier to use the MS' EF.

smurrell wrote:

I am using BreezeJS with it. Will it pull out the data from the database should Breeze ask for the additional data from the type?

I am thinking maybe I need to switch to use EF as I did in previous Breeze project. I just prefer using LLBLGen as I find the entire product easier to use the MS' EF.

Ah I see now what you're getting at: before you had an entity model, from which a 'single DTO type per entity' model was generated and that worked because there's no way to alter the nested types anyway.

With the DTO model we have you can model what you want to expose on the service, and persist (if you want to) the root derived elements on the round trip. So you have control over what's exposed through which DTO, as they're not meant to be 1:1 the same as the entity model, they're a projection of it.

So it's up to you what you need of course. We didn't write a Breeze support system as there are many JS libraries out there which do what Breeze does and we decided it was better to create a DTO / Doc DB model system instead which works with all the client JS libraries over a service.

I switched it to EF. I had to add the EntityFramework v6 to the persistence library though to get it to work. It seems to be working now.

What other JS libraries are out there which do what Breeze does?

smurrell wrote:

I switched it to EF. I had to add the EntityFramework v6 to the persistence library though to get it to work. It seems to be working now.

Yes, sadly we can't generate Nuget references which are automatically evaluated by building the project so that has to be done manually. (we can generate the packages.config, but the paths in it aren't known at generation time)

What other JS libraries are out there which do what Breeze does?

To my knowledge AngularJS and Ember both do change tracking of objects bound ? I'm sure Breeze does something extra, I don't know it that well, but the main feature that caught my eye was their change tracker / object tracker, which to my knowledge is also present in the big frameworks like Angular.