Introduction

The ODS/API solution (Ed-Fi-ODS.sln) contains a large number of assemblies. Some of these are shared with other applications, including Admin App and bulk-related utilities. Division of code into separate projects is a common* practice to provide that sharing capability, and to insure that classes and packages (assemblies, libraries) are coherent and dedicated to purpose. However, the current scheme has costs associated with it, including:

...

1. Look for opportunities to combine assemblies.
2. Consider carefully what code truly needs to be shared.
3. When code does need to be shared, should this be done through
   1. NuGet package, or
   2. Duplicated code, or
   3. Changing to a model of calling shared administrative services?

References

• Assembly Fiefdoms: What's the Right Number of Assemblies/Libraries? by Scott Hanselman

• C# Namespaces and Assemblies Best Practice Stack Overflow discussion

• Should you split your ASP.NET MVC project into multiple projects? by Mosh Hamedani

• Separate Assemblies != Loose Coupling by Jeremy Miller

Refactoring

Bulk Load Assemblies and Classes

• Consolidates all bulk-load related security classes by eliminating EdFi.Ods.Security.BulkLoad  and removing classes from EdFi.Ods.Security, placing all of the above into EdFi.Ods.BulkLoad.Core.
• Eliminates EdFi.Ods.BulkLoad.Services , an anemic project a single class (XmlShreddingDatabaseInstaller). This class was moved into EdFi.Ods.Standard.NHibernate.Mappings.SqlServer, as its single purpose - despite the name - is to load NHibernate-related classes into the Castle Windsor dependency injection container.