C#企业应用开发艺术CSLA.NET框架开发实战C#2008源代码资源-CSDN文库

共3个文件

pdf：2个

zip：1个

CSLA

CSLA.NET

4星 · 超过85%的资源需积分: 3 15 浏览量 2012-11-18 10:08:32 上传评论 2 收藏 7.04MB RAR 举报

资源推荐

资源详情

资源评论

收起资源包目录

ecsla2008代码.rar （3个子文件）

4252.pdf 2.06MB

4253.pdf 535KB

4198.zip 5.3MB

Expert C# 2008 Business Objects

electronic or mechanical, including photocopying, recording, or by any information storage or retrieval

system, without the prior written permission of the copyright owner and the publisher.

ISBN-13 (pbk): 978-1-4302-1019-1

ISBN-13 (electronic): 978-1-4302-1020-7

Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1

Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence

of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark

owner, with no intention of infringement of the trademark.

Editor: Matthew Moodie

Technical Reviewers: James Miller, Andrés Villanueva, Joe Fallon

Editorial Board: Clay Andres, Steve Anglin, Mark Beckner, Ewan Buckingham, Tony Campbell,

Gary Cornell, Jonathan Gennick, Michelle Lowman, Matthew Moodie, Jeffrey Pepper, Frank Pohlmann,

Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh

Project Manager: Richard Dal Porto

Copy Editors: Nicole Abramowitz, Jennifer Whipple

Associate Production Director: Kari Brooks-Copony

Production Editor: Laura Esterman

Compositor: Susan Glinert

Proofreader: Nancy Bell

Indexer: John Collin

Artist: April Milne

Cover Designer: Kurt Krames

Manufacturing Director: Tom Debolski

Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor,

New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail

orders-ny@springer-sbm.com, or

visit

http://www.springeronline.com.

For information on translations, please contact Apress directly at 2855 Telegraph Avenue, Suite 600,

Berkeley, CA 94705. Phone 510-549-5930, fax 510-549-5939, e-mail

info@apress.com, or visit http://

www.apress.com.

Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use.

eBook versions and licenses are also available for most titles. For more information, reference our Special

Bulk Sales–eBook Licensing web page at

http://www.apress.com/info/bulksales.

The information in this book is distributed on an “as is” basis, without warranty. Although every precaution

has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to

any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly

by the information contained in this work.

The source code for this book is available to readers at

http://www.apress.com.

Lhotka_1019-1FRONT.fm Page ii Thursday, November 20, 2008 5:04 PM

■ ■ ■

CHAPTER 1

Distributed Architecture

Object-oriented design and programming are big topics—entire books are devoted solely to the

process of object-oriented design or to using object-oriented programming in various languages

and on various programming platforms. My focus in this book isn’t to teach the basics of object-

oriented design or programming, but rather to show how you may apply them to the creation of

distributed .NET applications.

It can be difficult to apply object-oriented design and programming effectively in a physically

distributed environment. This chapter is intended to provide a good understanding of the key issues

surrounding distributed computing as it relates to object-oriented development. I’ll cover a number

of topics, including the following:

• How logical n-layer architectures help address reuse and maintainability

• How physical n-tier architectures impact performance, scalability, security, and fault tolerance

• The difference between data-centric and object-oriented application models

• How object-oriented models help increase code reuse and application maintainability

• The effective use of objects in a distributed environment, including the concepts of anchored

and mobile objects

• The relationship between an architecture and a framework

This chapter provides an introduction to the concepts and issues surrounding distributed

object-oriented architecture. Then, throughout this book, I’ll be exploring an n-layer architecture

that may be physically distributed across multiple machines. I’ll show how to use object-oriented

design and programming techniques to implement a framework supporting this architecture. I’ll

create a sample application that demonstrates how the architecture and the framework support

development efforts.

Logical and Physical Architecture

In today’s world, an object-oriented application must be designed to work in a variety of physical

configurations. Even the term application has become increasingly blurry due to all the hype around

service-oriented architecture (SOA). If you aren’t careful, you can end up building applications by

combining several applications, which is obviously confusing.

When I use the term application in this book, I’m referring to a set of code, objects, or components

that’s considered to be part of a single, logical unit. Even if parts of the application are in different

.NET assemblies or installed on different machines, all the code will be viewed as being part of a

singular application.

Lhotka_1019-1C01.fm Page 1 Wednesday, October 22, 2008 9:48 AM

CHAPTER 1

■ DISTRIBUTED ARCHITECTURE

This definition works well when describing most traditional application models, such as single-

tier or 2-tier rich client applications, n-tier smart client applications, web applications, and so forth.

In all those cases, the application consists of a set of objects or components that are designed to work

together within the context of the application.

You can contrast this with an SOA model, where multiple services (each essentially a separate

application) interact through message-based communication. In an SOA model, the idea is to build

an enterprise system that is composed of applications and services. In this context, both applications

and services are stand-alone, autonomous units of functionality, which means they both meet the

definition of an application. Confusingly enough, this means a service is merely an application that

has an XML interface instead of an HTML or graphical interface.

If you’re thinking about service-oriented systems as you read this book, the term application

means one of two things. First, it may refer to a service implementation. Second, it may refer to an

application on the edge of the system that allows users to interact with the system. Edge applications

are much like traditional applications, except they typically interact with services instead of data-

bases for retrieving and storing data.

You can contrast the traditional and SOA models with a workflow model, which you’re likely to

encounter when using Windows Workflow Foundation (WF). In this environment, an application is

often implemented (in whole or part) in the form of a workflow. However, the workflow itself merely

orchestrates a set of activities, and each activity should be an autonomous, stand-alone unit of func-

tionality. This means that an activity must meet the definition of an application. An activity is merely

an application that has no real user interface beyond the data-binding infrastructure built into WF.

Traditional, service-oriented and workflow applications might run on a single machine. However,

it’s very likely that they will run on multiple machines, such as a web server or a smart client and an

application server. Given these varied physical environments, you’re faced with the following questions:

• Where do the objects reside?

• Are the objects designed to maintain state, or should they be stateless?

• How is object-relational mapping handled when retrieving or storing data in the database?

• How are database transactions managed?

Before discussing some answers to these questions, it’s important that you fully understand the

difference between a physical architecture and a logical architecture. After defining these terms, I’ll

define objects and mobile objects, and show you how they fit into the architectural discussion.

When most people talk about n-tier applications, they’re talking about physical models in which

the application is spread across multiple machines with different functions: a client, a web server, an

application server, a database server, and so on. And this isn’t a misconception—these are indeed

n-tier systems. The problem is that many people tend to assume there’s a one-to-one relationship

between the layers (tiers) in a logical model and the tiers in a physical model, when in fact that’s not

always true.

A physical n-tier architecture is quite different from a logical n-layer architecture. An n-layer

architecture has nothing to do with the number of machines or network hops involved in running

the application. Rather, a logical architecture is all about separating different types of functionality.

The most common logical separation is into an Interface layer, a Business layer, and a Data layer.

These may exist on a single machine or on three separate machines—the logical architecture doesn’t

define those details.

■Note There is a relationship between an application’s logical and physical architectures: the logical architecture

always has at least as many layers as the physical architecture has tiers. There may be more logical layers than

physical tiers (because one physical tier can contain several logical layers), but never fewer.

Lhotka_1019-1C01.fm Page 2 Wednesday, October 22, 2008 9:48 AM

CHAPTER 1 ■ DISTRIBUTED ARCHITECTURE

The sad reality is that many applications have no clearly defined logical architecture. Often the

logical architecture merely defaults to the number of physical tiers. This lack of a formal, logical design

causes problems because it reduces flexibility. If a system is designed to operate in two or three phys-

ical tiers, then changing the number of physical tiers at a later date is typically very difficult. However,

if you start by creating a logical architecture of three layers, you can switch more easily between one,

two, or three physical tiers later on.

Additionally, having clean separation between these layers makes your application more main-

tainable, because changing one layer often has minimal impact on the other layers. Nowhere is this

more true than with the Interface layer (sometimes called the UI or Presentation layer), where the

ability to switch between Windows Presentation Foundation (WPF), Windows Forms, Web Forms,

ASP.NET MVC, and workflow and service-based interfaces is critical.

The flexibility to choose your physical architecture is important because the benefits gained by

employing a physical n-tier architecture are different from those gained by employing a logical n-

layer architecture. A properly designed logical n-layer architecture provides the following benefits:

• Logically organized code

• Easier maintenance

• Better reuse of code

• Better team-development experience

• Higher clarity in coding

On the other hand, a properly chosen physical n-tier architecture can provide the following

benefits:

•Performance

• Scalability

• Fault tolerance

•Security

It goes almost without saying that if the physical or logical architecture of an application is

designed poorly, there will be a risk of damaging the things that would have been improved had the

job been done well.

N-Tier and SOA

It is important to realize that a physical service-oriented architecture is not the same as an n-tier

architecture. In fact, the two concepts can be complementary. It is also important to know that the

concept of a logical n-layer architecture is the same in SOA as in any other type of application model.

In logical n-layer models, a service should have the same layers as any other application: Inter-

face, Business, and Data. In a logical n-layer model, the Interface layer consists of XML messages, but

that’s not a lot different from the HTML used in a web-based Interface layer. The Business layer is

much the same as in any other application; it contains the business logic and behaviors that make

the service useful. The data layer is also much the same as in any other application, in that it stores

and retrieves data as necessary.

However, the physical n-tier model might not appear to translate to the SOA world at all. Some

people would say that SOA makes n-tier concepts totally obsolete, but I disagree. SOA has an important

set of goals around loose coupling, reuse of functionality, and open communication. An n-tier client/

server architecture has a complementary set of goals around performance, avoiding duplication of

code, and targeted functionality. The reality is that both models are useful, and they complement

each other.

Lhotka_1019-1C01.fm Page 3 Wednesday, October 22, 2008 9:48 AM

CHAPTER 1

■ DISTRIBUTED ARCHITECTURE

For example, you might use a service-oriented model to create a service that is available on the

Internet. However, the service implementation might be n-tier, with the service interface on the web

server and parts of the business implementation running on a separate application server. The result

is a reusable service that enjoys high performance and security and avoids duplication of code.

Complexity

Experienced designers and developers often view a good n-tier architecture as a way of simplifying

an application and reducing complexity, but this isn’t necessarily the case. It’s important to recog-

nize that n-tier designs are typically more complex than single-tier designs. Even novice developers

can visualize the design of a form or a page that retrieves data from a file and displays it to the user,

but novice developers often struggle with 2-tier designs and are hopelessly lost in an n-tier environment.

With sufficient experience, architects and developers do typically find that the organization and

structure of an n-tier model reduces complexity for large applications. However, even a veteran n-tier

developer will often find it easier to avoid n-tier models when creating a simple form to display some

simple data.

The point here is that n-tier architectures only simplify the process for large applications or

complex environments. They can easily complicate matters if all you’re trying to do is create a small

application with a few forms that will be running on someone’s desktop computer. (Of course, if that

desktop computer is one of hundreds or thousands in a global organization, then the environment

may be so complex that an n-tier solution provides simplicity.)

In short, n-tier architectures help to decrease or manage complexity when any of these are true:

• The application is large or complex.

• The application is one of many similar or related applications that, when combined, may be

large or complex.

• The environment (including deployment, support, and other factors) is large or complex.

On the other hand, n-tier architectures can increase complexity when all of these are true:

• The application is small or relatively simple.

• The application isn’t part of a larger group of enterprise applications that are similar or related.

• The environment isn’t complex.

Something to remember is that even a small application is likely to grow, and even a simple

environment often becomes more complex over time. The more successful your application, the

more likely that one or both of these will happen. If you find yourself on the edge of choosing an

n-tier solution, it’s typically best to go with it. You should expect and plan for growth.

This discussion illustrates why n-tier applications are viewed as relatively complex. A lot of factors—

both technical and nontechnical—must be taken into account. Unfortunately, it isn’t possible to say

definitively when n-tier does and doesn’t fit. In the end, it’s a judgment call that you, as an applica-

tion architect, must make, based on the factors that affect your particular organization, environment,

and development team.

Relationship Between Logical and Physical Models

Some architectures attempt to merge logical n-layer and physical n-tier concepts. Such mergers

seem attractive because they seem simpler and more straightforward, but typically they aren’t good

in practice—they can lead people to design applications using a logical or physical architecture that

isn’t best suited to their needs.

Lhotka_1019-1C01.fm Page 4 Wednesday, October 22, 2008 9:48 AM

评论收藏

内容反馈

yingzhanqiu

2013-03-28

谢谢分享，确实是好东西，还没仔细研究
xx_fish

2013-12-20

挺复杂的，虽然代码算是挺全的，但是我这种菜鸟级的看起来有困难，不知道运行哪个
takumiwu

2013-05-14

这本书看了很多遍，很有技术含量
qianjinsong2007

2013-05-09

还不错，挺复杂的，还没研究
mengjianwen

2013-06-02

非常好，正是我想找的！！

前往

页

kelelipeng

粉丝: 2
资源: 45

C#企业应用开发艺术CSLA.NET框架开发实战C#2008源代码

C#企业应用开发艺术CSLA.NET框架开发实战

C#企业应用开发艺术CSLA.NET框架

C#企业应用开发艺术CSLA.NET框架开发实战.rar

《#企业应用开发艺术CSLA.NET框架开发实战》配套源码及例程csla-4.5.700

C#企业应用开发艺术CSLA.NET框架开发实战.part1.rar PDF加源码

C# .NET 微信公众平台SDK 微信快速开发框架源码2015-07

C#企业应用开发艺术：CSLA.NET框架开发实战

C#企业应用开发艺术CSLA_NET框架开发实战

《C#企业应用开发艺术--CSLA.NET框架开发实战》源码

C#企业应用开发艺术CSLA.NET框架开发实战.part2.rar

CSLA.NET框架开发实战Expert C#2008 Business Objects

[CSLA .NET] CSLA .NET 框架企业应用开发艺术 (2008 版本) (英文版)

[CSLA .NET] CSLA .NET 框架企业应用开发艺术 (2005 版本) (英文版)

CSLA.NET自动生成代码扩展模板

CSLA.NET框架源码

CSLA.NET框架开发小例子集合

.NET软件开发框架CSLA.NET.zip

CSLA.NET 4.5.601源码

一个最完整的基于Csla.net的vb源代码

[CSLA.NET] Using CSLA 4 eBook Series

ILSpy 安装包和压缩包

DevExpress22.X完美Patch资源

基于C#与Sql Server的智慧星学生选课管理系统.rar

CefFlashBrowser - Flash浏览器

用c# 自己封装的Modbus工具类库源码

vscode 1.77 安装包

HslCommunication.dll 7.0.1 免费版本 全部源代码和测试工程

C#使用 MQTTnet 快速实现 MQTT 通信 Demo

StockMonitorInstaller-1.0.13

最新资源

HslCommunication.dll 7.0.1 免费版本全部源代码和测试工程