c# - Tips on designing a .Net framework application -
can please provide me tips/guidelines when architecting, designing , implementing .net framework application, requirements given below:
- it analytical tool retrieve data files, sql databases , may cubes. data layer should able handle that. middleware should totally independent of other layers need ioc container (which 1 recommend)
- it deployed on local intranet
- the front layer might wpf application or silverlight in future (for now, concentrating on silverlight point change)
- it should easy customise , improve in future without changing of code framework deployed many clients
- i need way store configuration information, picked application on application load events set feel , look.
i have 2 months implement , looking many tips possible.
soc start
break application several assemblies use ioc (interfaces + implementations):
- application model assembly - other assemblies reference 1 because these classes used inter-communication - pocos
- presentation assembly - references app model , business services - 1 either wpf or silverlight in case use mvvm make testing life easier
- business services assembly - references app model , data repositories assembly
- data repositories - these define repositories data stores
then i'd create 3 additional ones:
- file data providers
- database providers
- cube providers
data repositories reference 3 , use them provide necessary data.
if configuration becomes complex lot of functionality should put in separate assembly , reference business services assembly.
which mvvm library use
since mentioned time suppose you'll have hard time catching deadline. when using mvvm (which suggested use) suggest don't use full blown prism (a.k.a. composite application guidance p&p) rather go mvvm light toolkit. take less time on bandwagon.
code generation
in places appropriate suggest use t4 full potential. use import stored procedure calls avoid using magic strings when calling stored procedures (and using parameters). check my blog post well.
dal technology/library
don't write own data access code using things sqlconnection
/sqlconnection
functionality. there're many data access layer libraries/technologies today can use , not reinvent wheel. if know nhibernate, use that. if know ef, use that. if know else, use that. provide/generate code possible tested , debugged.
so boils down to:
dry + yagni
a.k.a. don't repeat yourself , you ain't gonna need it = don't over-engineer code.
agile developers supposed lazy
they should develop as it's needed , no more! tdd implicitly provides process red => green => refactor steps.
Comments
Post a Comment