NOTE: *** I would like to suggest a forum to address WCF (Windows Communication Foundation) issues specifically. ***

I have issues regarding ProxyStubs or what I would call DTOs (Data Transfer Objects)  and would like to make the following suggestions:

 Currently, I use MyGeneration via the ES template, 'Proxy Stub - Client Side (C#)' to auto-generate the DTOs or 'proxy stubs' and the result is classes that are auto-generated similar to this:

       [XmlType(TypeName = "TestProxyStub")]

       [Serializable]

       public partial class TestProxyStub {

              public TestProxyStub() {

                     this.esRowState = "Added";

              }

 

              public System.DateTime Created {

                     get { return _Created; }

                     set {

                           this.SetDirty();

                           this._Created = value;

                     }

              }

              private System.DateTime _Created;

 

 

              public string esRowState {

                     get { return this._esRowState; }

                     set { this._esRowState = value; }

              }

              private string _esRowState = "Unchanged";

 

              public void MarkAsDeleted() {

                     this.esRowState = "Deleted";

              }

 

              private void SetDirty() {

                     if (this.esRowState == "Unchanged") {

                           this.esRowState = "Modified";

                     }

              }

       }

1. I would like the same customization ability available to the client as the service (I.e. have the classes inherit from a custom base class) to add modify features.
2. My personal preference is not to use partial classes and would like the option not to generate the classes as partial classes.
3. All the methods such as SetDirty(), or MarkAsDeleted need to be, at a mimium, virtual so that the logic can be customized.
4. In the application I am developing, the framework is highly customized. For example, it expects properties not to be "Dirty" if the value supplied matches the value already present. I use methods similar to this handle property changes:
   
   

                 protected static bool AreObjectsEqual(object oldValue, object newValue) {

                        if (Object.ReferenceEquals(oldValue, newValue))

                              return true;

                        if (oldValue is ValueType && newValue is ValueType && Object.Equals(oldValue, newValue))

                              return true;

                        if (oldValue is string && newValue is string && String.Equals(oldValue, newValue))

                              return true;

                        return false;

    

                 }
   
   

                 protected virtual bool SetPropertyValue<T>(string propertyName, ref T propertyValueHolder, T newValue) {

                        T oldValue = propertyValueHolder;

                        if (ObjectsAreEqual(newValue, oldValue))

                              return false;

                        this.RaisePropertyChanging(propertyName);

                        propertyValueHolder = newValue;

                        this.RaisePropertyChanged(propertyName);

                        return true;

                 }

   
   Thus, a property would look like this:
   
   

                 public System.DateTime Created {

                        get { return _Created; }

                        set {SetPropertyValue<System.DateTime>("Created", _Created, value);}

                 }

                 private System.DateTime _Created;

   
   

   Notice that property changing/changed events will not be raised if the same value is applied. Also, NOTE - A more complex version stores the original values for several reasons such as preventing saving a record if all the property values have not changed (i,e were changed and then changed back) as well as to provide undo capability.

 Any feedback?

 

Okay, we've created a new forum (and I've moved this post into it) for WCF Issues, you are right, this is needed.

1)  Yes, we should be able to do that

2) As for the partial classes this was a feature requested by another of our users - Isotope (I think) and it's not a bad idea, that way you can add methods and extend your proxies and not worry about losing those methods when regenerating. I'm not sure what harm having them be partial causes but let's get to the other issues.

3) Regarding the methods, IsDirty, MarkAsDeleted and so forth, I completely agree, these will be made virtual.

4) I like the idea of the true dirty flags on the proxies as well. Your true EntitySpaces objects do track whether columns are dirty and have on them a modified columns collection.

On the property changing events the only thing I see here is your turning the proxies into more full featured objects such as the full blown ES objects. Are you actually binding to them? Just curious, also, have you got your code now working between client/server using our WCF proxies?

I think for ES2008 will work work with you, Isotope (I think that's the right user) and a few others who are using our WCF classes as a sort of committee to make sure we get it right and the enhanced classes serve all of everyones needs. I'm pretty exciting about really improving them.

 

 

---

EntitySpaces | Twitter | BLOG | Please honor our Software License

>> 2) As for the partial classes this was a feature requested by another of our users - Isotope (I think) and it's not a bad idea, that way you can add methods and extend your proxies and not worry about losing those methods when regenerating. I'm not sure what harm having them be partial causes but let's get to the other issues.

Its not a "bad idea", but for a new user like me it makes me suspect another partial class is already implmented 'somwhere' and then I start searching for it.. I suspose if I knew i could opt out of generating a partial class, I would know there aren't any oother matching partial classes to worry about unless I create them. To me its a form of helpful documentation. However, its not a big deal, just a thought now that I do know.

>> On the property changing events the only thing I see here is your turning the proxies into more full featured objects such as the full blown ES objects. Are you actually binding to them?

 Yes, that is the idea. However, the extensions on the client are simply different than the service. The client needs properties related to data binding ,CRUD operations, etc. In some sense, the client-side objects are UI aware. This allows for a data manager class to take certain types (any proxy stub) and handle all the behavior thats repeated for each form. Each form then requires very little code.

>> Just curious, also, have you got your code now working between client/server using our WCF proxies?

 Well, yes and no. I can easily transfer the objects (which btw is very hard with most other ORMS) and that part is working well, but I also have an existing framework where I am trying to simply replace my old DTOs with ES DTOs (proxy stubs). My framework is designed with a library of custom user controls, and " data managers" for building the menus, buttons, etc. as nearly automatic as possible. Hence, I have many extended properties and methods and need to get those implemented before I can plug them in. I also need to override certain features such as BeginEdit, CancelEdit, and EndEdit. IMO some less than experienced  programmer with lofty ideas at Microsoft made the decision for some controls - primarily grids and data navigators  - to auto-call  these methods. Unfortunately, I don't know of a single application where the default behavior is acceptable. It would have been far easier if MS simply left it up to each respective developer to decide when and where these methods are called and never called them automatically; however, since they did and since their logic sucks (IMO), I MUST override these methods and implement my own version.

Personally, I am quite happy with proxy stubs being as bare as possible.  I do suggest calling a base class for property changes and doing the exact same thing as the server-side where there is an option for users to generate a custom base class and implement custom behavior within those custom base classes. I do not see a reason for generating custom classes for every type of client proxy stub, only bases classes. 

Trevor, I'm working on this now, have your thoughts changed on any of this, just making sure you haven't learned things that have shed more light on the subject?

---

EntitySpaces | Twitter | BLOG | Please honor our Software License

I am in the middle of one the hardest terms in college - ever - it has caused me to put some programming efforts in the backburner (frustrating).

Honestly, I am looking forward to the "layered"  model you have planned. Essentially, the proxy stub on the client interacts with the UI, so it needs the features that are UI related like handling property changed events. The server-side entity does not interact with a UI, it interacts with business logic. I cusomized all of my ES objects so they declare interfaces, ICustomer, IAddress, etc so that my business logic accepts any object that inherits the appropriate interface(s). It is complicated.

 Let me be clear - its all working now - with highly customized templates. If I weigh anyting that matters to me, of all aspects previously discussed, its the layered approach and I understand that it will take some time. Since, the current model works (with more effort), I am not panicked and am quite happy. With the layered approach for templates, I can share snippets, others can share snippets, and - theoretically, it will be much easier to customize ES objects for particular needs. Without using the layered model (its unavailable as of yet), or really knowing how you will achieve creating it, I can only guess. I anticipate one significant issue: that ES 'required' features related solely to persistence MUST be separated disstinctly from all other aspects. For example, INotifyPropertyChanged, how getters and setters are implemented, etc should remain customizable and separate from truly core features.