MSDN 架构师中心

http://msdn.microsoft.com/zh-cn/architecture/default.aspx

The list of books for Architect

http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx

Components and Tiers in Applications and Services

It has become a fairly widely accepted tenet of distributed application design that you should divide your application into components providing presentation, business, and data services. Components that perform similar types of functions can be grouped into layers, which in many cases are organized in a stacked fashion so that components "above" a certain layer use the services provided by it, and a given component will use the functionality provided by other components in its own layer and other layers "below" to perform its work.

Layers of a Windows Application

A Windows application can be divided into a number of logical layers. Your decision on which layers to implement and enforce typically depends on your quality of service (QOS) requirements.
For example, if your application is a stop-gap, possibly throwaway, system with low scalability and maintainability concerns, you might choose to implement only a couple of layers (UI and database). If, on the other hand, you are optimizing your architecture for varied physical deployments, high scalability, multiple user interfaces (Smart Client, Mobile, Reports, and so on), and a high degree of reuse, then you will opt to abstract your application into many more logical layers—you might even decide to create a framework that supports your layers. Most enterprise-level applications written today employ some version of the three primary layers:
user interface, middle tier, and database. Each of these layers might then be divided into additional layers. The following discussion presents each of these layers and some of their common divisions. Any combination of these layers may make up a Windows application.

User Interface A user interface layer provides a window to the application for users. This
layer is typically responsible for getting data from the middle tier and displaying it to the user.
It is also responsible for controlling how a user interacts with that data. This includes data
entry, validation, creating new elements, search, and so on. The UI layer is also in charge of getting the user’s modifications back to the middle tier for processing. The user interface layer is
often a layer by itself. However, it is also sometimes divided into one or more of the following
additional layers:
■ Presentation (or user experience) This layer defines only the presentation portion of the
user interface. This is the portion responsible for laying out the user interface. Think of
this code as the code inside of the FormName.Designer.cs, InitializeComponent method in
C#. Visual Basic hides this code from the developer. In both cases, Visual Studio is trying
to abstract the code for the forms engine and promote the use of the form designer tools.
■ User interface code This layer is where developers place the code to interact with the
user interface. The layer is typically embedded with the form. There is a partial class
associated with each form in both VB and C#. You put your code in this class and it gets
compiled with the form. The code that goes in this layer is to respond to events such as
loading a form or clicking a button. You might decide to abstract the code to respond to
these items into a separate user interface interaction layer. The code that would get compiled
with the form would then simply delegate calls to this layer. This will increase your
reuse if you intend to implement different forms that do the same thing or a new user
interface.
■ Business logic interaction code You might create this layer if you do not wish to tie the
code used to interact with your business layer (middle tier) to the user interface code.
This can be helpful if you intend to plan for the replacement of your user interface. For
example, you might create a Windows-based client today but have a plan to move to
Extensible Application Markup Language (XAML), an Office Client, or something even
further out.

Middle Tier The middle tier is where you house your business logic. This is often referred
to as just the business layer. However, this tier typically includes a lot more than just business
logic. It might include components for handling caching, logging, error management, and so
on. You might use the Microsoft Enterprise Library (or a similar library) in this tier. The middle
tier typically runs on an application server such as Windows Server and Internet Information
Services (IIS). However, you can create your own middle tiers (using things like Windows
services and sockets). The middle tier is sometimes divided into one or more of the following
additional layers:
■ Business layer (or business services) This layer is where you put your domain objects
and their business rules. You might be writing stateless components that work with
Enterprise Services, real object-oriented business objects that run in process, or simple
data transfer objects (DTOs) with processing services that work across remoting channels. In any case, most applications define a business layer. This isolates the business
logic so it can be reused, remain stable (as UIs get rewritten and modified), be
easier to change, and so on. As an example, a business layer object might be an Invoice
class. It might contain properties that define an invoice and methods that save and
load the object. These methods and properties will define the business rules for the
given object. These rules should be validated before the object is sent to another layer
for processing.
■ Application layer (or application services) This layer represents the plumbing to make
your application work. This plumbing typically solves QOS requirements such as “the
application must log errors or cache data for performance.” You want to keep this code
isolated from your business logic. Sometimes this code gets put into a framework. You
can also consider the Microsoft Enterprise Library as part of the application layer. Examples
of an application layer might include a Log class that contains methods to log certain
events, such as errors.
■ Database layer (or database services) This layer abstracts the retrieval and storage of
data in your database. This code is sometimes combined with the business layer. However,
this tight coupling can make the code harder to understand, more brittle to change,
and less reusable. As an example, the database layer might contain static (or shared)
methods that work to save and retrieve data from the database on behalf of the business
layer. An example might include an InvoiceData class with a method like GetInvoice that
returns a DataSet with invoice data. The database abstraction layer is often part of the
database layer. However, it typically does not reside on the database server but on the
middle-tier application server. That is why it is discussed here.

Database Layer The database layer represents how you manage the data in your application.
For most enterprise applications this means a relational database, such as Microsoft SQL
Server. The database layer is responsible for saving, retrieving, and ensuring the integrity of
your data. The database “tier” is sometimes divided into one or more of the following additional
layers:
■ Database layer See the previous “Middle Tier” section.
■ Stored procedures This layer represents the SQL or managed code used to select,
insert, update, and delete data with the database. It also includes any database-defined
functions you might create.
■ Integration services This layer represents how the database works with other data
sources for integration purposes. In SQL Server this is SQL Server Integration Services
(SSIS) or the older Data Transformation Services (DTS).
■ Database tables, log, and indexes This layer represents the actual data in the system,
the log of activity, and the indexes used by the database software.

Optimistic Concurrency (ADO.NET)

In a multiuser environment, there are two models for updating data in a database: optimistic concurrency and pessimistic concurrency. The DataSet object is designed to encourage the use of optimistic concurrency for long-running activities, such as remoting data and interacting with data.

Pessimistic concurrency involves locking rows at the data source to prevent other users from modifying data in a way that affects the current user. In a pessimistic model, when a user performs an action that causes a lock to be applied, other users cannot perform actions that would conflict with the lock until the lock owner releases it. This model is primarily used in environments where there is heavy contention for data, so that the cost of protecting data with locks is less than the cost of rolling back transactions if concurrency conflicts occur.

Therefore, in a pessimistic currency model, a user who updates a row establishes a lock. Until the user has finished the update and released the lock, no one else can change that row. For this reason, pessimistic concurrency is best implemented when lock times will be short, as in programmatic processing of records. Pessimistic concurrency is not a scalable option when users are interacting with data and causing records to be locked for relatively large periods of time.

Using UNIX Systems

http://www.udel.edu/topics/os/unix/

Visual C++ Multithreading

Visual C++

Multithreading

Visual C++ allows you to have multiple concurrent threads of execution running simultaneously. With multithreading, you can spin off background tasks, manage simultaneous streams of input, manage a user interface, and much more.

In This Section

Multithreading with C and Win32

Provides support for creating multithread applications with Microsoft Windows

Multithreading with C++ and MFC

Describes what processes and threads are and what the MFC approach to multithreading is.

Multithreading and Locales

Discusses issues that arise when using the locale functionality of both the C Runtime Library and the Standard C++ Library in a multithreaded application.

Unicode and MBCS

There is a topic about this title in MSDN.
It can be searched at http://msdn2.microsoft.com/en-us/library/default.aspx.

Thread issue 2

Nested multithread solution.

Thread issue 1

1. How to rework the code to make it meet multiple thread
2. Make out a caller side code

NamedPtr int g_counter = 0;
void IncCounter()
{
  g_counter++;
}

Prefer initialization to assignment in constructors

(From Item 12 of Effective C++)
Consider a template for generating classes that allow a name to be associated with a pointer to an object of some type T:

template
class NamedPtr {
public:
NamedPtr(const string& initName, T *initPtr);
...

private:
string name;
T *ptr;
};

(In light of the aliasing that can arise during the assignment and copy construction of objects with pointer members ( see Item 11), you might wish to consider whether

NamedPtr

should implement these function. Hint: it should (see Item 27).)