...
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 based on purpose 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 small 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
Refactorings
| Child pages (Children Display) |
|---|