Enterprise development commonly refers to the patterns and practices adopted by programmers endeavoring to implement enterprise architecture. It is the employment of certain approaches and methodologies that aim to achieve many of the root goals inherent to a successful enterprise system. What these goals are specifically changes from organization to organization; however, at the root, they address five key areas of system development:
1. Reliability
2. Flexibility
3. Separation of concerns
4. Reusability
5. Maintainability
These base tenets are embraced by all developers of enterprise systems, and they help to define the core of what most modern developers consider to be well - designed software. Enterprise development embraces these ideals, weaving them subtly into the tools and processes that drive software logic.
Reliability
Most would agree that designing systems that are reliable is a must. Yet coding for reliability is a departure from business as usual. This is especially true in the rapid application development community. Many enterprise enthusiasts exchange the term reliability for testability, since most modern enterprise coding patterns aim to facilitate unit testing. Writing code that can be well tested means changing the way that a system ’ s functionality is modularized. It means flattening out otherwise bloated classes and removing dependencies, or rather, removing references to other code that prevent a class or module from being tested. Many of these design patterns are integral to a process known as Test Driven Development, or TDD.
Flexibility
Requirements can change. As a result, so must the software that supports them. If the code that you write prevents an application or system from being extensible or pliable, we would say it lacks flexibility. Many people mistake the need for flexibility for other popular engineering subjects, such as interoperability. However, enterprise flexibility addresses the ability of code to be broken down and shared by different systems applications. A program might be functional on different platforms, or contain logic for lots of different failure scenarios, but that wouldn ’ t mean it was flexible. A flexible system allows for the changing of core features without violating unrelated services or attributes.
Separation of Concerns
Separation of concerns is simply the process of breaking a system or application down into distinct functional layers with limited overlapping of functionality. Like flexibility, separation of concerns addresses the ability to modularize code and make it more pliable, with the added benefit of logical division. Much of this division can be achieved through well - known object - oriented tenets, such as modularization and encapsulation. As we explore new patterns of development, separation of concerns becomes an all - important piece of the enterprise puzzle.
Reusability
Sharing features and services is tantamount to good enterprise design. As code is broken down and separated into logical pieces, these pieces should be designed to provide a distinct feature or satisfy a particular requirement of other systems that invoke it. The scope of a class ’ s reusability depends on the context in which it is used; however, most agree that other modular pieces of code within a similar context should always be callable. In other words, classes at any one logical level should be reusable by other classes in the same logical level. Classes that provide data should be consumable by all other classes that demand data within scope. Classes that implement a user interface (UI) behavior should deliver the same behavior to all UI - implementing classes on the same UI tier. The notion of reusability is especially important when designing true enterprise architectures.
Maintainability
Maintainability refers to the capacity of a system to be altered or modified. Although most software engineers think they know what maintainability means, it actually has a distinct meaning in the world of software design. According to the international standard of software development defined in ISO 9126, the term maintainability actually means the ease with which a software product can be modified in order to support:
• Stability
• Analyzability
• Changeability
• Testability
Maintainable code should be the natural result of following these four tenets, provided that the designer has not introduced unnecessary levels of complexity.
For a great many software engineers this can be a dramatic shift in the way they program. It requires a rigid manner of programming, employing new concepts and demanding more upfront design than the typical developer usually executes. At close glance, one might think that simple, non – enterprise computer code that delivers a particular feature is identical in value to enterprise code that delivers precisely the same feature. Yet this shortsighted evaluation fails to address the greater needs of the system, namely core enterprise concepts. While the code may deliver similar results, the enterprise code takes strides to accommodate better design. So while the enterprise sample might look a bit more complex (only at first, mind you), the resulting class or module ultimately provides more reliability or is more maintainable.
Consider a simple example. Two developers are required to build a web page that displays dynamic feeds of financial data. These feeds can range from stock quotes to bond prices to billboard articles from popular financial journals. The non - enterprise developer might write an ASP.NET page with a set of data grids, each bound to different database calls and online web services. The bindings are created in the ASP.NET code - behind page directly, placing a good amount of data logic side by side with some of the user interface behaviors. The enterprise developer would take a slightly different tack. Using the Model - View - Presenter pattern widely embraced within the enterprise community, they define a class to garner and hold the data on its own. They then create another class to handle the user interface logic and events, defining both classes with an abstract interface that defines each of the classes ’ core methods. Finally, the developer writes a series of unit tests and mock classes to test the code and ensure that all portions function as intended.
The resulting software delivers precisely the same page and the same data, with much more orchestration and modularity. So the two efforts were a wash, right? Let ’ s take this model a step further. The sample page hits its mark. Management is happy and they request that the page be published on the company website. The website requires a level of account authorization in order to query data from other data sources, but neither developer is aware of this. The non - enterprise developer deploys the web page directly and takes a quick look at it using a browser running on his/her desktop. They are logged in as an administrator, so the web page loads just fine. Unfortunately when others try to view the page they get a horrible system error that crashes the entire web session. On the other hand the enterprise developer took time to write a unit test that impersonates an anonymously authenticated user in the data access class. They run the test as a part of the build process and the problem becomes immediately apparent. The enterprise code is more reliable than the non - enterprise code. What ’ s more, the composition of the web page code to support the unit tests allows for modularity and separation of concerns. So when management provides a new data service to use, the data layer can be altered with minimal impact on the user interface. The code is now more flexible, too. The added flexibility, along with the reliability and logical separation, makes the enterprise developer ’ s web page far more maintainable than the non - enterprise developer ’ s page.
An enterprise architecture can be difficult to build in its entirety. Typically speaking, an individual software engineer has limited say over how a business expends its resources. For most developers this is a game - changing approach to writing code. The vast majority of developers in the Microsoft world concentrate on developing software for a single system or application. This is completely understandable when you consider that an overwhelming number of career Microsoft developers began as business analysts or specialists who, thanks to the proliferation of rapid application development tools in the
Microsoft software space, took on coding as a means of automation. Yet despite the upfront convenience of rapid application development, the cost in the long run can be, and usually is, very high. Enterprise development aims to reduce these long - term costs with prudent designs, approaches, and testability.
Source of Information : Wrox Professional Enterprise dot NET
1. Reliability
2. Flexibility
3. Separation of concerns
4. Reusability
5. Maintainability
These base tenets are embraced by all developers of enterprise systems, and they help to define the core of what most modern developers consider to be well - designed software. Enterprise development embraces these ideals, weaving them subtly into the tools and processes that drive software logic.
Reliability
Most would agree that designing systems that are reliable is a must. Yet coding for reliability is a departure from business as usual. This is especially true in the rapid application development community. Many enterprise enthusiasts exchange the term reliability for testability, since most modern enterprise coding patterns aim to facilitate unit testing. Writing code that can be well tested means changing the way that a system ’ s functionality is modularized. It means flattening out otherwise bloated classes and removing dependencies, or rather, removing references to other code that prevent a class or module from being tested. Many of these design patterns are integral to a process known as Test Driven Development, or TDD.
Flexibility
Requirements can change. As a result, so must the software that supports them. If the code that you write prevents an application or system from being extensible or pliable, we would say it lacks flexibility. Many people mistake the need for flexibility for other popular engineering subjects, such as interoperability. However, enterprise flexibility addresses the ability of code to be broken down and shared by different systems applications. A program might be functional on different platforms, or contain logic for lots of different failure scenarios, but that wouldn ’ t mean it was flexible. A flexible system allows for the changing of core features without violating unrelated services or attributes.
Separation of Concerns
Separation of concerns is simply the process of breaking a system or application down into distinct functional layers with limited overlapping of functionality. Like flexibility, separation of concerns addresses the ability to modularize code and make it more pliable, with the added benefit of logical division. Much of this division can be achieved through well - known object - oriented tenets, such as modularization and encapsulation. As we explore new patterns of development, separation of concerns becomes an all - important piece of the enterprise puzzle.
Reusability
Sharing features and services is tantamount to good enterprise design. As code is broken down and separated into logical pieces, these pieces should be designed to provide a distinct feature or satisfy a particular requirement of other systems that invoke it. The scope of a class ’ s reusability depends on the context in which it is used; however, most agree that other modular pieces of code within a similar context should always be callable. In other words, classes at any one logical level should be reusable by other classes in the same logical level. Classes that provide data should be consumable by all other classes that demand data within scope. Classes that implement a user interface (UI) behavior should deliver the same behavior to all UI - implementing classes on the same UI tier. The notion of reusability is especially important when designing true enterprise architectures.
Maintainability
Maintainability refers to the capacity of a system to be altered or modified. Although most software engineers think they know what maintainability means, it actually has a distinct meaning in the world of software design. According to the international standard of software development defined in ISO 9126, the term maintainability actually means the ease with which a software product can be modified in order to support:
• Stability
• Analyzability
• Changeability
• Testability
Maintainable code should be the natural result of following these four tenets, provided that the designer has not introduced unnecessary levels of complexity.
For a great many software engineers this can be a dramatic shift in the way they program. It requires a rigid manner of programming, employing new concepts and demanding more upfront design than the typical developer usually executes. At close glance, one might think that simple, non – enterprise computer code that delivers a particular feature is identical in value to enterprise code that delivers precisely the same feature. Yet this shortsighted evaluation fails to address the greater needs of the system, namely core enterprise concepts. While the code may deliver similar results, the enterprise code takes strides to accommodate better design. So while the enterprise sample might look a bit more complex (only at first, mind you), the resulting class or module ultimately provides more reliability or is more maintainable.
Consider a simple example. Two developers are required to build a web page that displays dynamic feeds of financial data. These feeds can range from stock quotes to bond prices to billboard articles from popular financial journals. The non - enterprise developer might write an ASP.NET page with a set of data grids, each bound to different database calls and online web services. The bindings are created in the ASP.NET code - behind page directly, placing a good amount of data logic side by side with some of the user interface behaviors. The enterprise developer would take a slightly different tack. Using the Model - View - Presenter pattern widely embraced within the enterprise community, they define a class to garner and hold the data on its own. They then create another class to handle the user interface logic and events, defining both classes with an abstract interface that defines each of the classes ’ core methods. Finally, the developer writes a series of unit tests and mock classes to test the code and ensure that all portions function as intended.
The resulting software delivers precisely the same page and the same data, with much more orchestration and modularity. So the two efforts were a wash, right? Let ’ s take this model a step further. The sample page hits its mark. Management is happy and they request that the page be published on the company website. The website requires a level of account authorization in order to query data from other data sources, but neither developer is aware of this. The non - enterprise developer deploys the web page directly and takes a quick look at it using a browser running on his/her desktop. They are logged in as an administrator, so the web page loads just fine. Unfortunately when others try to view the page they get a horrible system error that crashes the entire web session. On the other hand the enterprise developer took time to write a unit test that impersonates an anonymously authenticated user in the data access class. They run the test as a part of the build process and the problem becomes immediately apparent. The enterprise code is more reliable than the non - enterprise code. What ’ s more, the composition of the web page code to support the unit tests allows for modularity and separation of concerns. So when management provides a new data service to use, the data layer can be altered with minimal impact on the user interface. The code is now more flexible, too. The added flexibility, along with the reliability and logical separation, makes the enterprise developer ’ s web page far more maintainable than the non - enterprise developer ’ s page.
An enterprise architecture can be difficult to build in its entirety. Typically speaking, an individual software engineer has limited say over how a business expends its resources. For most developers this is a game - changing approach to writing code. The vast majority of developers in the Microsoft world concentrate on developing software for a single system or application. This is completely understandable when you consider that an overwhelming number of career Microsoft developers began as business analysts or specialists who, thanks to the proliferation of rapid application development tools in the
Microsoft software space, took on coding as a means of automation. Yet despite the upfront convenience of rapid application development, the cost in the long run can be, and usually is, very high. Enterprise development aims to reduce these long - term costs with prudent designs, approaches, and testability.
Source of Information : Wrox Professional Enterprise dot NET
|
|
0 comments
Post a Comment