Is there a better (organized) way of referencing Entity field in Linq?

BIZ TMS Aurelius
1

The following code using STRING CONSTANTS to reference Entity fields USER_ID, and ROLE_ID - it leads to a lot of duplicated code and error-prone.

Does Aurelius provide a "better" way than just using string constants? Can I use something like TUserRole.UserID (or like)?

    var LUserRole := FObjectManager
      .Find<TUserRole>
      .Where((Linq['USER_ID'] = LUSerId) and (Linq['ROLE_ID'] = LRoleId))
      .UniqueResult;
2

You may use a 'Dictionary' (can be automaticly generated with TMS Data Modeler)

So, instead of 'USER_ID' and 'ROLE_ID'

you can use Dic.UserRole.UserId and Dic.UserRole.RoleId

1 Like
3

Hi @Farias_Anderson Thank you for your help. I looked into the Dictionary approach.

I primarily use CodeFirst (not using Data Modeler much), and find the "Dictionary" approach cumbersome, and that it doesn't meet my need and personal preference.

I ended up doing the following, adding all column names to the const section manually. This way:

  • I can reference the column name elsewhere directly by TRole._RoleKey
  • Does not add much extra coding effort with CodeFirst
  • All the relevant information at one single place, i.e., where the entity class is defined.
  [Entity, Automapping]
  [Aurelius.Mapping.Attributes.Model(SecurityModel)]
  [Table('ROLES')]
  TRole = class
  const
    _RoleKey     = 'ROLE_KEY';
    _Description = 'DESCRIPTION';
  private
    FId: Integer;

    [Column(_RoleKey, [TColumnProp.Unique, TColumnProp.Required], 32)]
    FRoleKey: string;

    [Column(_Description)]
    FDescription: Nullable<string>;
  public
    property Id: Integer read FId write FId;
    property RoleKey: string read FRoleKey write FRoleKey;
    property Description: Nullable<string> read FDescription write FDescription;
  end;
1 Like
4

Unfortunately that's the only way to do so. That's a limitation of Delphi/Pascal language itself, since, for now, it doesn't provide a kind of "property reference" mechanism - or lambda expressions.

As a side note, keep in mind that when using Linq you work with the objects, thus it expects property and field names, not database column names. If your property is named RoleKey, it doesn't matter how it's named in the database, you should use

Linq['RoleKey']

to reference the object property, and not

Linq['ROLE_KEY']

5

@wlandgraf

Thank you for the reminder. I later figured that out (after quite some debugging time).

Probably it would be valuable to stress this information in user manual, so new users don't make the same mistake I made.

Thank you again.

1 Like
6

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.