.Net based Application development: How to get started….

Every phase of an application development lifecycle is interesting and each has got its own set of opportunities to improvise and challenges to understand and address from previous experience. And that’s what makes it interesting. Its evolution at its best when during the requirement cycle what seems impossible to understand during the first week of requirements analysis seems in control the week after that after those brainstorming discussions with the team (which involves the customer and the development team). Around that time you pretty much start off with putting the architectural blocks in place with respect to the requirements which brings in the much wanted clarity for the development team where the developer then starts to get the handle to his respective modules in the architecture which she/ he would own to completion. This phase is a very important and critical one (one to convert requirements to the first set of architectural blocks- logical/ deployment/ component/ technology/ product choice) and typically a technical architect plays a key role here.

A typical application architecture though supposed to serve varied set of requirements is at some level an improvisation of the prescriptive architecture given below (using it from www.codeplex.com):

And various constraints could be,

• “production has to be on such-and-such version only of .Net”
• Use Oracle database server than SQL since Oracle is our organization standard (or the other way around)
• We have third party application with which this application is supposed to interact and that can understand only pipe (and so on) separated text file format.
• And so on… this list typically is very huge

Depending on the above constraints one would end up filling in relevant blocks with relevant software versions. 

Once that is done, assuming that we talking about .Net 3.0/ 3.5 (or any other version of framework of other products), its important and imperative to put the code structure in place- grouping of server side logic/ client components (thick?/ thin?), test modules, the source control, bugs database and so on. And VSTS with source control comes in pretty handy there for most of the configuration parts. But still the solution structure which the distributed team would start to fill-in is not defined and as such this is a challenging part. This is where “Service Factory” comes into the picture- check http://www.codeplex.com/servicefactory for details. Service factory gives an amazingly productive start to a project. It lays down the complete solution structure which consists of various project layers corresponding to the above prescriptive architecture. 

Few important aspects worth noting here:

Service factory by default prescribes that we have separate entities for business (business entities) and service (service entities) and there is a conversion happening here from service entity to business entity whenever the server receives the calls from the clients, although this is of less overhead it eventually proves as a big maintenance overhead whenever few properties change/ get updated. There are ‘n’ numbers of places which have to be touched when updating is needed. With due consideration to all other principals for business entity creation, have a common entity as service entity and business entity always simplifies things as the project progresses.
The usage of service factory modeling edition as project progresses can prove to be a bit of overhead when only few properties have to be changed on a frequent basis and the entire code gets regenerated. And when the numbers of controllers (developers) are many who can change the schema it becomes all the more cumbersome to maintain.

My personal note: It is certainly recommended to use “Service Factory” and proves very productive for the phases which otherwise would be difficult to realize/ time consuming. 
Till this point the project can be said to be in a good first phase where the initial processes and code entities / host is in place . In my next article will post few more experiences from this phase to the testing/ production phase and tools which prove (d) very handy.