Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm exposing Data objects via service oriented assembly (which on future usages might become a WCF service).

The data object is tree designed, as well as formed from allot of properties.Moreover, some services return one objects, others retrieve a list of them (thus disables throwing exceptions).

I now want to expose data flow warnings and wondering what's the best way to do it having to things to consider: (1) separation (2) ease of access. On the one hand, I want the UI team to be able to access a fields warnings (or errors) without having them mapping the field names to an external source but on the other hand, I don't want the warnings "hanged" on the object itself (as I don't see it a correct design).

I thought of creating a new type of wrapper for each field, that will expose events and they'll have to register the one's they care about (but totally not sure) I'll be happy to hear your thoughts. Could you please direct me to a respectful design pattern? what pattern will do best here?

share|improve this question
You did a good job framing a problem, but you might want to rewrite the end a little to ask a specific question. Right now there's not a question in there at all :-) – DKnight Dec 18 '11 at 5:44
thank you. updated :) – Oren Schwartz Dec 18 '11 at 7:32
Just wondering, how would events propagate across layers? – NoChance Dec 18 '11 at 8:43
thought about having an IFieldErrorWrapper that'll encapsulate each field, and will expose its events. the UI will then decide how to handle them. – Oren Schwartz Dec 18 '11 at 9:43
@OrenSchwartz "others retrieve a list of them (thus disables throwing exceptions)," Why? What's wrong with sub-classing the list class with a custom implementation and wrapping the iterable property with exception handling logic, it's actually pretty easy to do. You could also implement a new exception interface to that all of the base data types inherit to guarantee commonality. If it's throwing an exception, expose an exception. – Evan Plaice Apr 18 '12 at 16:38
up vote 1 down vote accepted

Tackled similar problem few days back by using Observer pattern. Create observer classes in the main assembly of the service. Attach error message observer to it. You can also attach error log as an observer.

share|improve this answer
Hi Omkar, Thanks first of all. Could you please point me to a similar solution to the one you used ? Thanks, Oren. – Oren Schwartz Mar 20 '12 at 0:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.