Sunday, May 15, 2011

Separation of concerns: The proper use of technologies

Have you ever written or programmed in such a way of convoluting functionality with business rules, data transfer objects, Domain driven Design (DDD), ORM standards etc into one single partition of your enterprise level application.
  1. Do you at all, think of your system as a piece of components with its own concerning functionality?
  2. How often do you do pure object orientation? (How often do you conceptualize your application as real world artifacts)
  3. Do you just code to solve business problems, or do you engineer code to be used to solve business problems?
  4. Do you have overlapping functionalities frequently in your projects?
  5. How do you integrate your system with legacies or third party? (Do you just integrate or add a layer of integration).
  6. Do you examine the commonalities and/or variabilities of your system before re-inventing the wheel.
  7. Do you know the paradigm: System of Systems
  8. What about aspect oriented programming? (how do you keep cross cutting concerns at bay?)
I can go on and on, but I'd thought i should take it from simple facts, so that upcoming software engineers/developers are inculcated. The success factor of an enterprise application development, is the domain knowledge, how often do you review and conceptualize your domain?

Domain engineering (Now called product engineering) is a systematic way of conceptualizing application components into families of systems to be later reused to solve problems within the domain. Although the concept of domain engineering is a different topic for another day, most software development IDE's are beginning to integrate this concepts into their systems.

Again: What is separation of concern
Separation of concern is a computer programming paradigm that stressed out the abilities to modularize , conceptualize , hides external impediments , follow LOD (law of Demeter or principle of least knowledge).

Although technologies had helped improve software development from 10 folds into higher number of folds in recent times, still, most development lack the knowledge of bringing this technologies together, rather they create an over complicated system which undermine the intentions of advancing technologies.

Are new technologies really new?
New technologies are not really new, they a proven approaches/standards blueprints which had been adopted by wider communities in the past before it became a technology. I would say, make a research on a new technology to understand its root and to understand what the drive and multivations are in the first place.

Latest .NET most misunderstood technologies
  1. ASP.NET MVC. Try to understand what the real MVC paradigm means. MVC is not a technology but a methodology.
  2. WCF is not RPC (Remote procedure call). The contract first development is not actually contract first, its Interface/Code contract first because this will still auto generate the WSDL , xml schema's etc. try to manually create wsdls and schema when integrating with different languages or platforms. Or understand how this work and how you can leverage message based achitecture instead.
  3. Entity Framework: Is not an holy grail nor a silver bullet. ORM's has their strengths and weaknesses, use patterns with ORM's or avoid most pitfalls when using ORM's.
  4. AJAX: Do you understand XMLHttpRequest and Response? have a look into the root of all AJAX evils, its a must understand.
  5. WWF: Why the sudden changes in .NET 4. When to use and how to reduce its noise.
  6. MEF: managed extensibility framework. very nice, but it is not a replacement for dependency injection framework.
This list goes on and on, but for now, i will stop here and let us have a think. Microsoft did invest alot on these technologies and upcoming technologies for us to have our concerns separated.