Wednesday, September 27, 2006
General Geekify: SpCore
This is an acronym for Splashers technologies library of reusable code classes. The current version targets the .Net framework 1.1 and has codes which are mostly generic for windows and web applications.
The application currently builds into a single dll, SpCore.dll.
Current code base has classes that handle Diagnostics, Exceptions, IO, Security, scanning and some utilities including some email abstractions and printing.
A number of namespaces exist under the main solution including Diagnostics. Here we have classes and static methods to push information to the Windows EventLog, we have ApplicationAssert, Auditing and application logs. Another is Exception with some exception classes that are particular to SpCore and an unhandled exception manager class.
Others include IO which has static methods to generate a byte array from a file, copy streams from a source to a destination, get file encoding and check validity of filenames among others, a security namespace which encapsulates IIdentity and IPrincipal, password hashing etc. Other namespaces handle printing of images, validations of web urls, emails, and names and so on. Also included are classes that handle serialization and imaging.
Since we will be refactoring SpCore for better adoption by the development team, we agreed to:
1. Pull out Util.Enumeration class. Most applications have enumerations particular to them and the more generic enumerations are already contained in the base class library e.g. DateTime.DayOfWeek
2. Extend the encryption and related library. This list of reusables is often used in applications and usually takes time repeat implementing
3. Redefine the architecture.
There will be a 1.1 version targeting .Net framework 1.1 and another targeting 2.0 and subsequent releases of the .Net framework.
• Library for .Net framework 1.1
• Library for .Net framework 2.0
Maintenance and reuse: Separate class library projects will be created for different areas e.g. SpCore.Securities, the names will not change between frameworks as framework information will be reflected in assembly versions.
We will introduce dependency libraries like SpCore.Shared to handle inter library dependencies and eliminate cyclic redundancies. Typical assemblies will have names like SpCore.Utilities.
As mentioned above, windows hold version information, SpCore does not carry target platform in its library i.e. SpCore1.1.Utilities or SpCore2.0.Utilities. Instead we will simply have SpCore.Utilities and use versioning and assembly signing to handle the target framework.
Environmental variables like web, windows do not reflect in assemblies ordinarily.
When we do need to get specific however, we append .Win or .Web or .Mobile e.g. Spcore.Win.Scanning or Spcore.Web.Scanning. When it’s generic, it simply carries SpCore.Scanning;
4. Planning for scalability: Ownership of contributions is primarily with the author.
When developers make interesting hacks or breakthroughs, the teams do a code review and decide if the code is redefining functionalities in the base class library or fit for SpCore. SpCore gets reviewed intermittently for additions and subtractions.
5. Documentation. We stick with Xml documentation and use tags like remarks to add additional/upgrading information.
6. Testing: - Owners submit unit test/test plans with code submission to SpCore. Core review may evolve additional plans and ethics. Generally codes will be added that conforms to naming standards and best practices.
Immediate steps:
• Refactoring SpCore to adopt new architecture: at code review 14th October 2006
• Fill out existing codes that contain stubs and pull out duplication of BCL
The application currently builds into a single dll, SpCore.dll.
Current code base has classes that handle Diagnostics, Exceptions, IO, Security, scanning and some utilities including some email abstractions and printing.
A number of namespaces exist under the main solution including Diagnostics. Here we have classes and static methods to push information to the Windows EventLog, we have ApplicationAssert, Auditing and application logs. Another is Exception with some exception classes that are particular to SpCore and an unhandled exception manager class.
Others include IO which has static methods to generate a byte array from a file, copy streams from a source to a destination, get file encoding and check validity of filenames among others, a security namespace which encapsulates IIdentity and IPrincipal, password hashing etc. Other namespaces handle printing of images, validations of web urls, emails, and names and so on. Also included are classes that handle serialization and imaging.
Since we will be refactoring SpCore for better adoption by the development team, we agreed to:
1. Pull out Util.Enumeration class. Most applications have enumerations particular to them and the more generic enumerations are already contained in the base class library e.g. DateTime.DayOfWeek
2. Extend the encryption and related library. This list of reusables is often used in applications and usually takes time repeat implementing
3. Redefine the architecture.
There will be a 1.1 version targeting .Net framework 1.1 and another targeting 2.0 and subsequent releases of the .Net framework.
• Library for .Net framework 1.1
• Library for .Net framework 2.0
Maintenance and reuse: Separate class library projects will be created for different areas e.g. SpCore.Securities, the names will not change between frameworks as framework information will be reflected in assembly versions.
We will introduce dependency libraries like SpCore.Shared to handle inter library dependencies and eliminate cyclic redundancies. Typical assemblies will have names like SpCore.Utilities.
As mentioned above, windows hold version information, SpCore does not carry target platform in its library i.e. SpCore1.1.Utilities or SpCore2.0.Utilities. Instead we will simply have SpCore.Utilities and use versioning and assembly signing to handle the target framework.
Environmental variables like web, windows do not reflect in assemblies ordinarily.
When we do need to get specific however, we append .Win or .Web or .Mobile e.g. Spcore.Win.Scanning or Spcore.Web.Scanning. When it’s generic, it simply carries SpCore.Scanning;
4. Planning for scalability: Ownership of contributions is primarily with the author.
When developers make interesting hacks or breakthroughs, the teams do a code review and decide if the code is redefining functionalities in the base class library or fit for SpCore. SpCore gets reviewed intermittently for additions and subtractions.
5. Documentation. We stick with Xml documentation and use tags like remarks to add additional/upgrading information.
6. Testing: - Owners submit unit test/test plans with code submission to SpCore. Core review may evolve additional plans and ethics. Generally codes will be added that conforms to naming standards and best practices.
Immediate steps:
• Refactoring SpCore to adopt new architecture: at code review 14th October 2006
• Fill out existing codes that contain stubs and pull out duplication of BCL
