1

So a lot of the web says not to use public nested types unless you need the member visibility semantics (including this msdn article, even though that article hasn't been touched since 2008).

For the most part, I agree with the line of logic.

However, I am writing code right now that's performing deserialization of complex object graph from consumer APIs, as well as serializing them into custom formats. So for example lets say an API returns the following:

{
    "productDetails": {
        "id": 1234,
        "name": "test"
    },
    "sku": {
        "skuId": "something",
        "category": "abcd",
        "regions": {
            "useast": {
                "availability": "full",
                "prices": [
                    {
                        "minimum": 0,
                        "price: 5,
                    }
                ]
            }
        }
    }
}

In order to deserialize this I need ~5 classes, a Product, Product Details, Sku, Region, and Price POCO.

So without using nested types I end up with

public class Product { }
public class ProductDetails { }
public class Sku { }
public class Region { }
public class Price { }

This has several issues in my mind, but the biggest is pollution of the namespace. There are other endpoints that return the concept of a product (for example a product list) but those products look different than the product details I get from this endpoint. There are other APIs that return information about Regions but are not product specific, so you end up with a lot of ProductRegion style namings and consumers have to figure out which Region they want in any given situation.

Except, while thinking about it all of these classes (except the outer most Product class) has zero usage outside of Product on a conceptual/domain level. No one is going to be passing around prices or regions or skus without also referencing the outer most Product, because in this case these pieces of information don't have relevance outside of serialization and deserialization scenarios. Yet they must be public for obvious consumption reasons.

So it seems to me that

public class Product 
{ 
    public class Details { }
    public class Sku { }
    public class Region { }
    public class Price { }
}

Seems like a good option in this scenario.

Is there any reason I should consider this a bad practice, specifically for serialization and deserialization purposes?

2 Answers 2

1

This sounds like a case where nested namespaces can be useful. Other clients can see the classes if they have a reason to, but they are not imported by most clients and are conceptually walled off both to prevent name collision and to help mental organization.

0

If you only need those classes for deserialisation then consider just using a dynamic object instead. You can use an anonymous type to serialise data. It will save you a lot of code if you have your own product classes

You can see that in particular the "regions" node is problematic for a strongly typed language and in general the whole thing is a bit of a mess.

A nice API would provide a c# client library and models

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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