What are the "standard framework" code that we should build?

Question

We are in a situation whereby we have 4 developers with a bit of free time on our hands (talking about 3-4 weeks).

Across our code base, for different projects, there are a number of framework-y type of code that is re-written for every new project that we start. Since we have some free time on our hands, I'm in the process of creating a "standard" set of libraries that all projects can re-use, such as:

1. Caching
2. Logging

Although these 2 above would rely on libraries such as Enterprise Library, each new project would write its own wrappers around it, etc, so we're consolidating all these code.

I'm looking for suggestions on the standard libraries that you built in-house that is shared across many projects.

To give you some context, we build LOB internal apps and public facing websites - i.e. we are not a software house selling shrink-wrap, so we don't need stuff like a licensing module.

Any thoughts would be much appreciated - our developers are yearning to write some code, and I would very much love to give them something to do that would benefit the organization in the long run.

Cheers

Answer 1

• Unit Testing Infrastructure - can you easily run all your unit tests? do you have unit tests?
• Build Process - can you build/deploy an app from scratch, with only 1 or 2 commands?

Answer 2

Some of the major things we do:

• Logging (with some wrappers around TraceSource)
• Serialization wrappers (so you can serialize/deserialize in one line of code)
• Compression (wrappers for the .NET functionality, to make it so you can do this in one line of code)
• Encryption (same thing, wrappers for .NET Framework functionality, so the developer doesn't have to work in byte[]'s all the time)
• Context - a class that walks the stack trace to bring back a data structure that has all the information about the current call (assembly, class, member, member type, file name, line number, etc)
• etc, etc...

Hope that helps

Answer 3

ok, most importantly, don't reinvent the wheel!

Spend some time researching libraries which you can easily leverage:

• For logging I highly recommend Log4Net.
• For testing nUnit
• For mocking, Rhino.

Also, take a look at Inversion of Control Containers, I recommend Castle Windsor.

• For indexing I recommend Solr (on top of Lucene).

Next, write some wrappers:

These should be the entry point of you API (common library, but think of it as an API).

Focus on abstracting all the libraries you use internally in your API, so if you don't want to use Log4Net, or Castle Windsor anymore, you can by writing well structured abstractions and concentrating on loosely coupled design patterns.

Adopt Domain Driven Development:

Think of API(s) as Domains and modular abstractions that internally use other common APIs like you common Data Access library.

Suggestions:

I'd start with a super flexible general DAL library, that makes it super easy to access any type of data and multiple storage mediums.

I'd use Fluent nHibernate for the relational DB stuff, and I'd have all the method calls into the you data access implement LINQ, as it's a c# language feature.

using LINQ to query DBs, Indexes, files, xml etc.

Answer 4

Here is one thing that can keep all developers busy for a month:

1. Run your apps' unit tests in a profiler with code coverage (nUnit or VS Code Coverage).
2. Figure out which areas need more tests.
3. Write unit tests for those sub-systems.

Now, if the system was not written using TDD, chances are it'd be very monolithic and will require significant refactoring to introduce test surfaces. Hopefully, at the end of it you end up with a more modular, less tightly coupled. more testable system.