+1  A: 

I would name it InventorySaveArgs just in case you ever want to make the type available to other types to use. If you name it InventorySaveArgs from the beginning then you will have a name that is meaningful in all contexts if you ever need to refactor.

Andrew Hare
+1  A: 

IIRC .NET Design Guidelines are pretty clear on this - there should be no public nested types.

jachymko
Not correct. You should *avoid* public nested types, but sometimes there are valid reasons to use them: http://msdn.microsoft.com/lv-lv/library/ms229027(en-us).aspx
Kyralessa
okay, there's an extremely rare exception to that rule, but it does not apply here.
jachymko
For a CLR example of exceptions, see the WinForms ListView, which has six nested public collection types. They're nested because they're intended to be used with the ListView. Other WinForms controls have similar nested types.
Kyralessa
+1  A: 

I would choose the first, create an outer class and name it InventorySaveArgs. If the particular class is used in a public method, the only argument for not including it outside the class is namespace pollution.

Having the inner class is quite frankly annoying in C# because you must constantly prefix the type name with the name of the class. As stated, once it's public the only motivation for donig this is reduction of namespace pollution. But if your namespace is so big that the InventorySaveArgs class is making it too big you probably need to break up your namespace anyways.

JaredPar
+1  A: 

The only pattern for encapsulating multiple parameters to a single object I've ever heard of is a refactoring pattern detailed by Martin Fowler

Manrico Corazzi
+1: What an aptly named pattern.. Parameter Object.. Who would have guessed! Thanks
Sung Meister