Tips on designing a .Net framework application
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
- It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
- It will be deployed on the local intranet
- The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
- It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
- I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
- application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
- presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
- business services assembly - references app model and data repositories assembly
- data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
- file data providers
- database providers
- cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.