次の方法で共有

Smart Client Architecture Guide is now live on MSDN

  • [アーティクル]

The Smart Client Architecture Guide is now live on MSDN

msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scag.asp

The performance chapter is being completed as we speak and should be posted in a week or so. We decided to put the rest of the guide out there since it has generated a lot of interest. Feedback welcome!

Comments

  • Anonymous
    June 17, 2004
    I skimmed the architecture guide yesterday and have a question about business validation behind the web service.

    So, you can do validation on the client but it's really just to avoid doing a round trip to the server. The problem is that the server side code can't trust that the data it recieves has been validated and is compliant.

    Say you want the WS to take a dataset that represents changes that need to get saved. These changes represent modifications to multiple business objects. The business objects get final say on what is and isn't valid data. Anything that isn't valid, doesn't get saved and gets kicked out.

    Is there any slick way to do this other than iterating through the rows and calling the public properties on the business objects?

    I guess I'm looking for more of an "idiot check" on the way I plan to implement the client-to-ws-to-business interactions. Does this sound like a good way to do this or am I thinking about my WS architecture all wrong?

    Thanks,
    -Ben




  • Anonymous
    June 18, 2004
    Yes, you are right - you need to validate on the server as well as the client. The validation at each end will be similar but not the same.

    Validation on the client provides better responsiveness and usability – you can validate each field and across many fields to ensure that you catch the obvious errors and are not going to waste the server’s time. Validation on the server will do much the same as the client plus it will ensure consistency with other data and business objects with respect to other user’s changes. Since there is usually a fair bit of overlap between the client and the server you should try to factor the common validation rules into an assembly that can be re-used on both the client and the server.

    I terms of implementing the rest of the validation on the server, you will either have to ensure consistency at the database level (databases are great for doing this!) or at the business object level. To support the latter your business objects should provide a batch update facility where you can make many changes to the object in one go rather than making multiple smaller changes, each of which will kick off some kind of validation resulting in a performance hit.

    Any validation errors have to be sent back to the client. If you are iterating over a DataSet where each row represents business object changes, then you may have to batch up any errors so that the valid changes are applied but the ones which aren’t successful are reported to the client.