Traditional wisdom says not to call into child namespaces from a parent.
Let’s say I’m using something like AutoMapper to translate content models into viewmodels for an ASP.NET MVC 3 site.
My directory structure looks similar to this:
- Stuff.Content
-Foo.cs
- Stuff.Content.Public
-Controllers
-FooController.cs
-Models
-FooViewModel.cs
-Views
-Foo
-Index.cshtml
- AutoMapperConfig.cs
- Global.asax
AutoMapperConfig.cs in this case is just a simple static class with a static method to set up the mapping, and looks like this:
public static class AutoMapperConfig
{
public static void Configure()
{
Mapper.CreateMap<Foo, FooViewModel>();
}
}
You’ll notice I’ve got AutoMapperConfig in the root of the public project, but it’s actually calling into a child namespace (Stuff.Content.Public.Models).
Is calling into that child namespace acceptable? Should AutoMapperConfig live in the Models namespace with the viewmodels?
It seems like it gets fuzzy in this territory since it’s considered normal for controllers in the Controllers namespace to call its sibling Models namespace.
Looking forward to your thoughts. Thanks.
I don’t think there’s anything wrong with your current design. Personally I put the mapping configurations into a
Mappingssubfolder folder:Also I tend to have a separate mapping file definition for each domain model.
And here’s an example of
FooProfile.cs:and
MappingRegistry.cs: