The notion of code separation is one of the single most important facets of enterprise development. Traditional Microsoft developers have at their fingertips a wide array of powerful RAD tools that empower them to quickly automate macros and execute applications. Unfortunately, these tools don ’ t enforce a strong degree of modularity. Although the code produces a desired result, the result is limited and not entirely reusable. Well - designed code must be broken down and divided into separate “ vehicles of purpose. ” In the enterprise world, these are known as units of codes. Units of code are typically classes or types designed with a specific purpose in mind. The purpose should be well focused, striving to achieve the single desired goal for which the type was initially designed. As various units of code are developed, they can be designed to interact with one another in a manner that achieves a larger desired effect without violating the rules that drive their division.
We know this sounds pretty confusing at first, but take heart — most seasoned Microsoft developers still have a tough time thinking in terms of true separation. When it comes to developing business applications the vast majority of us are wired to think of the desired outcome and then work backward. Think about most of the business requirements for which you ’ ve developed code. A manager or project leader gives you the task of building a thing that does X. You then work backward from X, constructing the code line by line in your mind until you have a rough roadmap for a prototype. You then translate this roadmap into whatever code gets the desired outcome the quickest in order to produce the results for the tasking manager. Yet this process skips the critical step of assessing code design before you write the code. The result is a pile of spaghetti code that isn ’ t reusable and, moreover, isn ’ t testable.
In cases such as these, it is critical for the developer to assess the design early, and understand the individual elements that will be needed to make the system function. Consider a requirement where you are tasked with creating a small client application that creates automated email newsletters advertising discounted auto parts. You ’ re given a list of discounting rules based on the location where a user lives, and a small desktop database containing the list of automotive parts and their prices. Another database
is given to you containing a list of user emails and the geographic location from which each user hails. Finally, you ’ re provided with a brief list of preferred styles for HTML - compliant email clients. Generally speaking, an application like this is a no brainer. Most developers experienced with Microsoft Office automation or simple ET.NET forms programming could create a console application that gets the job done in a handful of function calls. Yet the resulting code is unorganized. It combines UI styles, database calls, and business rules into one convoluted stack of code.
Most developers have experimented with some modularity in the past. You might have moved recursive calls into a separate function, maybe created a class or two for accessing data, or perhaps you ’ ve dabbled with some object - oriented design patterns, like a Factory model or Decorator pattern. Wouldn ’ t these deliver an acceptable amount of modularity? Not necessarily. Patterns such as these do provide a useful means of separation; however, when developing enterprise systems modularity isn ’ t just about separation of your code for reusability. Enterprise development typically requires a strong degree of loose coupling.
Source of Information : Wrox Professional Enterprise dot NET
We know this sounds pretty confusing at first, but take heart — most seasoned Microsoft developers still have a tough time thinking in terms of true separation. When it comes to developing business applications the vast majority of us are wired to think of the desired outcome and then work backward. Think about most of the business requirements for which you ’ ve developed code. A manager or project leader gives you the task of building a thing that does X. You then work backward from X, constructing the code line by line in your mind until you have a rough roadmap for a prototype. You then translate this roadmap into whatever code gets the desired outcome the quickest in order to produce the results for the tasking manager. Yet this process skips the critical step of assessing code design before you write the code. The result is a pile of spaghetti code that isn ’ t reusable and, moreover, isn ’ t testable.
In cases such as these, it is critical for the developer to assess the design early, and understand the individual elements that will be needed to make the system function. Consider a requirement where you are tasked with creating a small client application that creates automated email newsletters advertising discounted auto parts. You ’ re given a list of discounting rules based on the location where a user lives, and a small desktop database containing the list of automotive parts and their prices. Another database
is given to you containing a list of user emails and the geographic location from which each user hails. Finally, you ’ re provided with a brief list of preferred styles for HTML - compliant email clients. Generally speaking, an application like this is a no brainer. Most developers experienced with Microsoft Office automation or simple ET.NET forms programming could create a console application that gets the job done in a handful of function calls. Yet the resulting code is unorganized. It combines UI styles, database calls, and business rules into one convoluted stack of code.
Most developers have experimented with some modularity in the past. You might have moved recursive calls into a separate function, maybe created a class or two for accessing data, or perhaps you ’ ve dabbled with some object - oriented design patterns, like a Factory model or Decorator pattern. Wouldn ’ t these deliver an acceptable amount of modularity? Not necessarily. Patterns such as these do provide a useful means of separation; however, when developing enterprise systems modularity isn ’ t just about separation of your code for reusability. Enterprise development typically requires a strong degree of loose coupling.
Source of Information : Wrox Professional Enterprise dot NET
|
|
0 comments
Post a Comment