In addition to d@nish's reply... Wauna wrote: I've tried to define a namespace for both services, hoping that would allow WCF to consider the two types equal; The namespaces would need to be the same for both, and the error message shows clearly they are not. As d@nish mentioned, if your services are in separate assemblies, then you should put the HCOPOrder in a library assembly and both service assemblies should reference the library. Then everyone shares the same namespace.class. If both your services are in the same assembly, then you shouldn't have two copies (in two namespaces) of the class definition....there should only be one. Mark Salsbery Microsoft MVP - Visual C++ :java:

Does it satisfy the requirements of a good user interface (assuming it ultimately leads to software someone uses and not a machine or other software). I tend to think about the requirements and the user experience first, even mock up a UI on paper. Try to eliminate as much work or complexity on the part of the user as possible so that the user can focus on accomplishing *tasks* rather than manipulating data. Once I have that decided the rest is easy because it simply has to meet the criteria of satisfying the task oriented design decisions. If you start from the bottom up on the other hand then you are faced with uncertainty at every level and ultimately could end up with a very computer programmer oriented design but not a user friendly design. (i.e. the end user get's exposed too much to the inner workings of tables and databases and how the computer and software works instead of simply being able to view it as a machine that helps them accomplish the tasks they already know and understand). This is the essential pivot point between what users percieve as "good" software and what users perceive as "bad" software. "The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying." - David Ogilvy

Wauna, There is a ton that can be said about design and architecture and there is no way to fully answer you question here. That being said, after reading your summary a few things strike me. 1) Can you identify entities on the spreadsheet that are, or can be, represented by objects? If so, then you may need to rethink your architecture to leverage those objects instead of a spreadhseet. 2) Don't tie the UI for data entry to the layout of the report. Or perhaps a better way of saying this is, don't assume that the method off data entry must mirror the report layout or vis versa. A spreadhseet may not only not lend itself to easy validation in a web app, but it may not be the most optimal form of data entry for your end users. Just a few thoughts, take 'em or leave 'em, but there they are.

big discussion on that in the lounge last week. MrPlankton

In my search for information on how to design validation, I did find this as well. The only problem is that I'm working with VS 2003. I don't think I can do the .NET 3.0 stuff with that. Can I? If I cannot do the 3.0 stuff, I'm torn, because it doesn't make any sense to re-work what's already been done with the Application Blocks. I'm already using the older application blocks for data access, logging, and exception logging.

also the abstraction allows you to come up with new gateways. let's say you've got the window object on your machine in a SQL DB but you connect your laptop to head office. You can now pass the window SOAPServerWindowGatewayObject and the window is synchronized with Head Office. Equally that could be an IPartListPrintOutGateway etc I'm sure the potential list is almost limitless. Russ

You want to look at some code of how design patterns etc are applied. MSDN has some really cool sample applications. These applications are full n-tier design and gets stuck right into new concepts like software factories as well as best practices Try the Microsoft .NET PetShop 4.0 http://msdn2.microsoft.com/en-us/library/Aa479070.aspx