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:
- Compile-time overhead, and
- Difficult to isolate development teams working on different applications that share resources.
(* common, but not necessarily "best" practice).
To address these related problems, and thus improve the development experience for not only the Alliance staff and contractors, but also the Ed-Fi community, the Alliance plans to take several steps:
- Look for opportunities to combine assemblies.
- Consider carefully what code truly needs to be shared.
- When code does need to be shared, should this be done through
- NuGet package, or
- Duplicated code, or
- 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
ODS-3134 - Getting issue details... STATUS
- Consolidates all bulk-load related security classes by eliminating
EdFi.Ods.Security.BulkLoadand removing classes fromEdFi.Ods.Security, placing all of the above intoEdFi.Ods.BulkLoad.Core - Eliminates
EdFi.Ods.BulkLoad.Services, an anemic project a single class (XmlShreddingDatabaseInstaller). This class was moved intoEdFi.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.