A Customer should have a collection of Orders, and Orders should have a collection of LineItems. As soon as you create a customer, you know you need orders, therefore, instantiate a collection of orders. Do not leave it null but leave it empty and then orders can be added. If orders are not allowed to be added then throw exception or handle it some other way. Leftyfarrell wrote: you simply have a Collection that is null. Like I said above this should be empty but not null--at least this is how I will design it. When a customer enters a store, he/she grabs a shopping cart but it is empty and then if he/she needs something she adds it. If he/she does not grab a shopping cart then what? Someone else has to grab it--I don't know about this. CodingYoshi Artificial Intelligence is no match for Human Stupidity.

Yeah, I guess my question is targeting the classes that might normally be created by an ORM. In our case, they are WCF data contracts, and have no behaviour. The system also has other classes with behaviour, such as a UserBusinessManager class, that exposes methods for working with a User object, to perform actions like Load, Update, Insert, etc.

Great discussion guys. Thanks for the comments and sorry I was away for a while... this tab got lost within 40 others in my Firefox window... For now, what we wound up doing is something like this: Global.Common assembly contains base classes for Validation. Logic to load validation error message strings is different depending on what "area" of the application you are calling validation from, ie. UI vs. BLL Each of our "areas" also has an assembly for common code (shared among the assemblies in that area) so we have: UI.Common and BLL.Common For the validation example... we created a validation class in UI.Common that inherits from Global.Common, but provides its own implementation that loads the message strings from our BLL by calling through WCF. We will create another validation class in the BLL.Common that inherits from Global.Common, but this implementation will call the BLL methods directly to load the message strings, without going through WCF. This way, the cross-cutting concerns are kept within the 3 Common assemblies and uses a provider model idea for the loading of message resources.

Unit testing and statics are always a rich topic of discussion. ;) Ultimately, what it boils down to is whether you think testing the static Globalization type is acceptable when your actually unit testing something else. If you are unit testing UserMapping, and mocking GlobalizationAdapter, your also interaction testing Globalization. At some point, you need to interaction test, to make sure that when A uses B, the interaction of the two behave like you would expect. Sometimes you can achieve this with a mock...sometimes you need to test the interaction of two real objects. Testing has a variety of forms: unit testing, interaction testing, acceptance testing, build verification testing, etc. Unit tests will only take you so far, and you can plug the holes and double up by performing other kinds of testing. In the case of your static Globalization class, it sounds like its a pretty simple type that acts as a lazy-loaded lookup? If its basically just a facade around a dictionary and some loading logic, I would not bother mocking it away, and just include it with your UserMapping unit tests. If Globalization is a richer class, and provides a variety of globalization services, it might be better to mock it away. You would want to unit test Globalization in isolation as well, to make sure you cover code that wouldn't be covered by interaction testing. If you do indeed need to mock away static types, there is one product that will let you do it: TypeMock Isolator. TypeMock's Isolator lets you mock absolutely anything, statics included. Its a pretty unique mocking framework that really helps you get the job done when nothing else will. Couple caveats: 1) its not free, and 2) it requires that all testing processes be spawned from its isolator root process that enables all the advanced call interception and whatnot.

I don't know very well the Laws, but I think that if you create a businness "in a totally unrelated field" you won't be sued. But you should be warned that if you use any mean (phone, computer, xerox, fax, e-mail etc ...) provided by your company for your personnal use (private or for your business) you may be fired. If you use the contact that you have with a person (that person being employed in the same company than you or not) in your daily work for your own business, it could be risky too. If you separate well your work "at work" and your business "at home" I don't see on what basis they could sue you (unless you work all night for your business and you sleep at work).

I did mean 1 OR 2 selected. By saying 1 and 2 = 3, I meant that the search criteria is defined for me by a user selecting options, and if they select options 1 and 2, I need to pull anyone that matches 1 OR 2. Their interface assumes an OR condition on the options they select. I believe what you have provided is what I need. I just need to test a bit more. Thank-you.

You will need some how to replace the & character with & amp; This way the XmlDocument object will confuse and will translate the & amp; as & only. You will then have & amp;apos; in the memory, which should become & apos; when you get it. Hope it helps.

Thanks alot for sharing, it's appreciated.

Yeah it is a WTF! OTOH you could say that this applies to any application. I've yet to use any application that does not crash unexepectedly under some circumstances! :) Kevin

You’ve signed a contract; you need to honor it. If it’s not physically possible you had best confess early and make the necessary adjustments. If you bid high and it was accepted you are lucky. We are all unlucky at times so try to leave a little slack. I bid $2000(US) on an embedded project “for a useable system.” I knew I was the only bidder and going much higher would cause the bid to be rejected. Part of the project involved compiled in control scripts. Editing these scripts on this system was needed. But the system was usable without script editing. I got an extra 1.5K. I ended up working for over 300 hours on the thing but even that low rate was better than nothing. And it put an interesting item in my resume.

The Session data is accessible to all the web pages within the user context, so if data is specific for a web page, IMHO you may think of a way to persist the control id in the web page scope, for example using the ViewState. However, the ViewState data is loaded after the Init phase, so you can manage to use the hidden field in the way you want.

Leftyfarrell wrote: Unfortunately, it doesn't help those of us who are still stuck using 1.1 and 2003 due to work environments, etc. Me too! But I play with 2005 at home and on my laptop when I bring it into the office. Kevin

Upon re-reading my post, I fear I might have rambled too much. Main question is this. Shared DLL assembly that will be used by 100's of web apps. What is the best way to deploy this shared assembly, considering the shared assembly version is not fixed... it may need to be updated once per month. GAC? this would mean regression testing the dependent apps(100's) for each new version. /bin folder? this would mean multiple versions of the shared assembly in use at any 1 time. What deployment method is best? thanks.