Tip

SOA basics - architecture in .NET

Last week's .NET developer tip discussed the definitions of patterns and architecture. This week, we continue the discussion with a deeper look into architecture. This tip, excerpted from InformIT,

    Requires Free Membership to View

talks about the kinds of decisions that you have to make before you build an application, and the answers serve to define the architecture of that application. These decisions are common concerns in service-oriented architecture (SOA) and in Web services development.

The architecture of an application results from the process of building a system from a variety of disparate components (some of which may themselves encompass design patterns) and making sure that those components come together in a flexible, maintainable, scalable, secure, and efficient way. In framework applications, architecture typically comes together through answering questions such as the following:

  • Should I use DataSets or DataReaders?
  • Should I use XML Web Services or .NET Remoting?
  • Should I use Windows or Forms authentication in ASP.NET?
  • Is multithreading necessary for this application?
  • Should I store data in DataSet objects or custom classes?
  • Where should I place domain logic?
  • Do I need to support multiple database back ends?
  • Should I use a Web or Windows UI?
  • How should I validate data?
  • How do I handle exceptions?

The answers to these questions and many more like them aren't always obvious, and the nature of the questions implies that there are multiple possible solutions and no "best way" in all cases.

Just as with design patterns discussed previously, these decisions (and parallel decisions made on non–.NET platforms) are ones that have been made many times over. As a result, you can benefit from the work of others who have collected architectural patterns and best practices that encapsulate many of these decisions. Two primary resources for framework developers include Patterns of Enterprise Application Architecture, by Martin Fowler (Addison Wesley Professional, 2002), and Application Architecture for .NET: Designing Applications and Services, posted on the MSDN Web site. In addition, Microsoft has collected a variety of architectural resources, including reusable code, Webcasts, and articles on its .NET Architecture Center Web site. I highly recommend that you obtain these resources if you're designing framework applications.

The Fowler book, in particular, is very helpful in fostering a common design vocabulary; it includes code examples in a variety of languages, including C#. In all, Fowler documents 51 patterns and, like the GoF, collects them in 10 higher-level groups:

  • Domain logic patterns. Define common approaches for organizing business logic, such as Transaction Script and Domain Model.
  • Data source architectural patterns. Patterns used to represent data within an application, such as Table Data Gateway and Data Mapper.
  • Object-relational behavioral patterns. A set of patterns that address the behavior of objects, including Lazy Load and Unit of Work.
  • Object-relational structural patterns. Patterns that deal with the structure of individual objects, such as Identity Field and Foreign Key Mapping.
  • Object-relational metadata mapping patterns. Patterns that address how relational data is mapped to objects and include patterns such as Metadata Mapping and Query Object.
  • Web presentation patterns. Patterns that implement the presentation for a Web site and include Front Controller, Page Controller, and Template View, among others.
  • Distribution patterns. Patterns that address how objects can be used remotely and include Remote Facade and Data Transfer Object.
  • Offline concurrency patterns. Patterns that are concerned with how multiple users update the same data. Several of the patterns are Optimistic and Pessimistic Offline Lock.
  • Session state patterns. Patterns that deal with how session state is handled in a Web application, including Server Session State and Database Session State.
  • Base patterns. Patterns that are used throughout the other patterns and include such ubiquitous patterns as Layer Supertype and Service Stub.

To read the entire article from which this tip comes, click over to InformIT. You have to register there, but the registration is free.


This was first published in May 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.