You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the only method for only returning or updating specific fields is on the class level. This requires either many partially duplicate classes, or manually constructing inheritance chains. Neither of these options support multiple inheritance, and they don't play nice with code generation (see #11 ).
I think at least having the option of using interfaces would be simpler:
A BaseDto subclass can implement one or more interfaces
In addition to the current single-parameter CRUD methods that return a whole object, the Dao CRUD members can take two generic parameters; the second is the interface to input/return, and the first remains the underlying class for the operation.
Only gettable members of the interface are used in query conditions (once we implement LINQ, see LINQ Provider #12 ) and in reads / query results. Only settable ones are used for creates/updates.
If you generate partial classes, then consumers can scope the object to all of their needs by slapping on as many interfaces as they want. The interfaces would not need the attributes, so these would be easy to write too.
To take an example: suppose I want just want to read just the Name and OrderNumber properties on DemoPurchaseOrder, and update the FooBar property on the Items (leaving the attributes off of the classes for simplicity; the interfaces would not need them):
publicclassDemoPurchaseOrder:BaseDto,IDemoPurchaseOrder_UpdateFooBar{publicoverridestringName{get;set;}publicintOrderNumber{get;set;}publicstringCustomerName{get;set;}publicstringCustomerEmail{get;set;}publicIList<Item> Items {get;set;}}publicclassItem:BaseDto,IItem_UpdateFooBar{publicstringBaz{get;set;}publicstringFooBar{get;set;}}publicinterfaceIDemoPurchaseOrder_UpdateFooBar{stringName{get;}intOrderNumber{get;}IList<IItem_UpdateFooBar> Items {get;set;}}publicclassItem:BaseDto,IItem_UpdateFooBar{stringFooBar{set;}}//pseudocodevardemoOrder=
gravityRsapiDao.GetRelativityObject<DemoPurchaseOrder,IDemoPurchaseOrder_UpdateFooBar>(1047088, ObjectFieldsDepthLevel.FirstLevelOnly);foreach(varitemin demoOrder.Items){return item.FooBar =$"{demoOrder.Name}_{demoOrder.ItemNumber}";//item.Baz is not available to set//demoOrder.CustomerEmail is not available to get}
gravityRsapiDao.Update(IDemoPurchaseOrder_UpdateFooBar>(demoOrder, ObjectFieldsDepthLevel.FirstLevelOnly);
The text was updated successfully, but these errors were encountered:
Right now, the only method for only returning or updating specific fields is on the class level. This requires either many partially duplicate classes, or manually constructing inheritance chains. Neither of these options support multiple inheritance, and they don't play nice with code generation (see #11 ).
I think at least having the option of using interfaces would be simpler:
BaseDto
subclass can implement one or more interfacesIf you generate partial classes, then consumers can scope the object to all of their needs by slapping on as many interfaces as they want. The interfaces would not need the attributes, so these would be easy to write too.
To take an example: suppose I want just want to read just the
Name
andOrderNumber
properties onDemoPurchaseOrder
, and update theFooBar
property on theItems
(leaving the attributes off of the classes for simplicity; the interfaces would not need them):The text was updated successfully, but these errors were encountered: