Clever Geek Handbook

Entity Names Entity

For domain objects, do property names need to be preceded by the entity name? I.E. my Warehouse class has a WarehouseNumber property. Should this property be called WarehouseNumber or just Number?

Thoughts?

+1


source to share


4 answers


I prefer not to use a prefix, I find it easier to type and a more readable context that the essence is almost always obvious.



+3


source


Think about the concepts you present, the context in which they appear, and their relative frequency.

In this case, the data fragments Warehouse

and Number

. In context Warehouse

, Number

has the appropriate qualifications. Outside Warehouse

, WarehouseNumber

will have the appropriate qualifications, i.e. Order.WarehouseNumber

...



Warehouse.WarehouseNumber

then it will be redundant.

+2


source


I would never prefix them in your code. You should always have meaningful variable, property, and method names that make the prefix redundant.

var currentWarehouse = warehouseService.Find(id);

var number = currentWarehouse.Number;

or

var number = order.Warehouse.Number;

I have settled on this when it comes to storing them in the database. There is something to say:

select   *
from     dbo.Warehouse
where    WarehouseId in (
             select   WarehouseId
             from     ...
         )
+1


source


This is one of those object-relational impedances that don't match mofos correctly. In OO, of course, the entity name prefix seems inappropriate. However, in RDMBS, the object prefix uniquely identifies the attribute and it is recommended to avoid this:

SELECT PostCode --OMG !!! What table am I coming from! C.PostCode or S.PostCode ??! ??!

FROM Client C

INNER JOIN Supplier S ON C.PrefferredSupplierID = S.SupplierID

My advice is to pick a conditional and stick to it roughly. This is an agreement to save time! Probably doesn't matter .. :)

0


source






More articles:


All Articles