Dim ond sylw sydyn fod yna wahaniaeth pwysig iawn rhwng y ddau ddiffiniad:

<Maes FieldBind = "InParam1" DesignerType "StringBuilder =" ID = "2" Testun = "Mewnbwn paramedr #1" />

yn erbyn:

<Maes FieldBind = "InParam1" ID = "2" Testun = "Mewnbwn paramedr #1" />

Mae'r cyntaf yn dangos fel hyn yn SPD:

tra bod yr ail yn dangos fel hyn:

Nid wyf yn siŵr pa mor ddefnyddiol yw'r lluniau sgrin hyn ond fe wnes i ymdrech i'w gwneud felly mae'n rhaid i chi eu gweld 🙂

Yr arsylwi yw hyn: StringBuilder yn eich galluogi i adeiladu llinyn (yn amlwg) drwy gymysgu gyda'i gilydd lythrenyddion llinyn a data llif gwaith (drwy gyfrwng y "ychwanegu chwilio am" botwm yn y gornel chwith isaf). Pan Defnyddiwch y botwm chwilio am ychwanegu, Mae'n mewnosod tocyn ar ffurf"[%tocyn%]". Pan mae SharePoint yn rhyw eich gweithred bersonol, (C # cod yn fy achos i), SharePoint yn pasio y tocyn ei hun, Nid gwerth y tocyn. Os ydych yn defnyddio math dylunio diofyn (yr ail fath), SharePoint ehangu tocyn ac yn pasio gwerth gwirioneddol y tocyn i'ch weithredu.

StringBuilder = BAD, Math o dylunydd rhagosodyn = DA.

Wrth gwrs, Dyna ni hyn mewn gwirionedd a olygaf. Dim ond peidiwch â geisio a throsglwyddo paramedr eich gweithred bersonol pan y dylunydd math = StringBuilder. Yn defnyddio'r math dylunio diofyn a'r gadwyn StringBuilder iddo ymlaen llaw os oes angen i adeiladu llinynnau cymhleth yn eich llif gwaith (sydd gyda llaw yn union hyn y mae un yn ei wneud i greu bwnc deinamig ar gyfer y camau e-bost, ond mae hynny'n bwnc ar gyfer mynediad blog arall, har har).

<diwedd />