使用CSLA .NET 4进行数据访问

5星 · 超过95%的资源需积分: 10 5 浏览量更新于2024-07-28 4 收藏 2.52MB PDF 举报

"Using CSLA 4 - 03 - 数据访问" 是一本电子书，主要探讨了CSLA .NET框架支持的四种数据访问模型，重点关注两种提供了最佳可维护性和灵活性，而不会增加过多复杂性的模型。这本书由Rockford Lhotka撰写，详细介绍了如何实现封装的调用和工厂实现数据门户模型，并展示了ADO.NET、ADO.NET实体框架以及模拟数据库访问技术的使用。书中包含多个示例应用，提供完整的持久化实现，以配合书中的概念和技术。这本书是"Using CSLA 4"电子书系列的一部分，购买系列书籍会自动获得此书。该系列旨在展示如何利用CSLA框架构建适用于Windows、Silverlight和Web的强大且可扩展的应用程序。 CSLA .NET是一个全面的框架，这意味着它有许多选项，可以支持更高级的场景。系列中的其他电子书为特定技术和使用场景提供了更深入的内容。编辑由Teresa Lhotka担任，源代码（CSLA 4版本4.1.0）可在作者的网站上获取，同时鼓励读者报告任何错误或对书籍的反馈。本书的内容包括： 1. **数据访问模型**：详细介绍了两种推荐的数据访问模型，即封装的调用（Encapsulated Invoke）和工厂实现的数据门户（Factory Implementation Data Portal）。这两种模型旨在在不增加额外复杂性的情况下，提高代码的可维护性和灵活性。 2. **技术演示**：通过实例展示了如何使用ADO.NET进行直接数据库操作，使用ADO.NET实体框架进行ORM（对象关系映射），以及如何使用模拟数据库访问技术进行单元测试和隔离。 3. **业务对象角色**：针对不同的业务对象类型，如简单对象、值对象、静态业务类等，阐述了如何在这些对象中实现数据访问模型。 4. **示例应用程序**：提供了完整的应用程序示例，这些示例涵盖了书中讨论的各种技术，帮助读者理解并实践CSLA .NET框架的使用。 5. **CSLA .NET框架**：简要介绍了CSLA .NET框架的基本原理和设计目标，以及它如何支持开发人员构建可复用、可扩展和易于维护的企业级应用。 6. **电子书系列**：强调了"Using CSLA 4"系列的结构和目的，指出每本电子书虽独立，但共同构成了一个全面了解CSLA 4的资源。 7. **责任声明和许可**：指出书中的信息“按原样”提供，不提供任何保证，作者不对因书中信息导致的任何直接或间接损失负责。源代码可在指定网址获取，并欢迎读者提供错误报告和反馈。通过阅读这本书，读者将能够掌握如何在实际项目中运用CSLA .NET进行高效、灵活的数据访问，并了解如何利用这个强大的框架构建企业级应用程序。

Using CSLA 4: Data Access Page 5

Rev 1.0

The business object contains the state necessary to implement its behaviors as defined by the

user scenario or use case.

The data access layer (DAL) contains the behaviors that directly interact with the data store to

fetch or update data.

The purpose of the data access invocation concern may be less obvious. In a simplistic view, the

business object and DAL interact to persist the object’s state. But something needs to coordinate

the interaction between the business object and the DAL, and this is the purpose of the data access

invocation concern. I am separating out the idea that some code must coordinate or orchestrate

how the business object interacts with the DAL or visa versa.

Data Portal Models

The CSLA .NET data portal supports two models for data access invocation. Each model has two

variations with regard to where the DAL is implemented. I discussed these four models in Chapter 3

of the Using CSLA 4: CSLA .NET Overview ebook.

Encapsulated Models

Two of the four models encapsulate the data functionality within the business classes. The data

access code itself may be in an external data access component, or it may be implemented directly

within the business class.

Either way, the basic structure of a business class is consistent. This example shows the code

necessary to implement a Fetch operation:

[Serializable]

public class PersonEdit : BusinessBase<PersonEdit>

{

public static void GetPersonEdit(int id, EventHandler<DataPortalResult<PersonEdit>> callback)

{

DataPortal.BeginFetch<PersonEdit>(id, callback);

}

#if !SILVERLIGHT

public static PersonEdit GetPersonEdit(int id)

{

return DataPortal.Fetch<PersonEdit>(id);

}

private void DataPortal_Fetch(int id)

{

// invoke external DAL here (encapsulated invoke)

// or implement DAL code here (encapsulated implementation)

}

#endif

}

The asynchronous and synchronous factory methods invoke the client-side data portal to initiate

the Fetch operation. The client-side data portal uses convention and configuration to determine

how to communicate with the server-side data portal. Remember that the “server-side” data portal

will be running on the physical client machine in a 1- or 2-tier deployment.

The server-side data portal creates an instance of the business class and invokes the

DataPortal_Fetch method, passing the criteria value provided by the factory method into the

DataPortal_Fetch method.

Using CSLA 4: Data Access Page 6

Rev 1.0

You can implement DataPortal_Fetch to interact with an external data access component; a

model called encapsulated invocation. Or, you can implement the data access code directly in the

DataPortal_Fetch method; a model called encapsulated implementation.

Silverlight and WP7

The DataPortal_XYZ methods are slightly different when implemented on Silverlight or WP7. The

reason for this is that all server access from Silverlight is required to be asynchronous, and the most

common implementation of a DataPortal_XYZ method on Silverlight is to call a remote SOAP or

REST service.

If the remote service call is asynchronous, then the DataPortal_XYZ method must also be

asynchronous. This means that the method must accept a callback parameter so the calling code

can be notified when the asynchronous operation is complete.

The method must also be public because of limitations on dynamic method invocation and

reflection in Silverlight and WP7.

Here’s an example of DataPortal_Fetch for Silverlight or WP7:

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

public void DataPortal_Fetch(

int id, Csla.DataPortalClient.LocalProxy<PersonEdit>.CompletedHandler handler)

{

try

{

// invoke external DAL here (encapsulated invoke)

// or implement DAL code here (encapsulated implementation)

handler(this, null);

}

catch (Exception ex)

{

handler(null, ex);

}

Notice that the method is public, and that it accepts a CompletedHandler parameter that must

be invoked when the method is complete. It is also a void method, because all results are returned

through the callback handler.

It is critical that the callback parameter be invoked when the method is complete,

whether an exception occurs or not. If the callback parameter isn’t invoked, the data

portal won’t know that the method has completed. The application will be stuck

thinking the data access operation is still running.

If the code in the DataPortal_XYZ method does invoke an asynchronous service or other

asynchronous operation, the callback handler should not be invoked until the asynchronous

operation is complete.

I often use the EditorBrowsable attribute from the System.ComponentModel namespace to

“hide” the method from Intellisense. Ideally this method would be non-public because it should

never be called except by the data portal. Unfortunately, due to limitations on reflection and

dynamic method invocation in Silverlight and WP7, the method must be public. The

EditorBrowsable attribute helps minimize the impact by hiding the method from developers using

the business type.

Using CSLA 4: Data Access Page 7

Rev 1.0

Factory Models

Two of the four models require implementation of a factory object that manages the data access

interaction for the business type. The data access code itself may be in the factory class, or it may

be in an external data access component invoked by the code in the factory class.

Either way, the basic structure of the business and factory classes are consistent. This example

shows the code for a business class using a factory model:

[Serializable]

[ObjectFactory("MyApp.DataAccess.PersonFactory,MyApp.DataAccess")]

public class PersonEdit : BusinessBase<PersonEdit>

{

public static void GetPersonEdit(int id, EventHandler<DataPortalResult<PersonEdit>> callback)

{

DataPortal.BeginFetch<PersonEdit>(id, callback);

}

#if !SILVERLIGHT

public static PersonEdit GetPersonEdit(int id)

{

return DataPortal.Fetch<PersonEdit>(id);

}

#endif

}

The ObjectFactory attribute on the business class tells the data portal to create and use a

factory object to manage the data access interaction for this business type. The attribute requires

that a factory name be supplied. By default, this name is the assembly qualified name of the factory

type. You can create a custom factory loader that interpets this value in any way you choose.

The asynchronous and synchronous factory methods invoke the client-side data portal to initiate

the Fetch operation. The client-side data portal uses convention and configuration to determine

how to communicate with the server-side data portal. Remember that the “server-side” data portal

will be running on the physical client machine in a 1- or 2-tier deployment.

Notice that there’s no DataPortal_Fetch method in the business class. When using a factory

model, there are no DataPortal_XYZ methods in the business class. All data access related code is

in a separate factory class. The server-side data portal creates an instance of the factory class and

invokes a Fetch method on the factory object, passing the criteria value provided by business

class’s static factory method into the Fetch method.

This example shows a factory class that supports the Fetch operation for the PersonEdit

business class:

public class PersonFactory : ObjectFactory

{

public PersonEdit Fetch(int id)

{

var result = new PersonEdit();

// implement DAL code here (factory implementation)

// or invoke external DAL here (factory invoke)

MarkOld(result);

return result;

}

In a factory model, the factory is responsible for several steps, including the following:

Using CSLA 4: Data Access Page 8

Rev 1.0

 Creating the business object instance

 Invoking or implementing the data access code

 Managing the business object’s metastate

 Returning the business object as a result

Although there’s no requirement that a factory class inherit from the ObjectFactory base class,

this base class does provide protected methods that make it easier to implement a factory class.

Silverlight and WP7

As with the encapsulated models, if you implement an object factory that will run on Silverlight or

WP7 the methods must accept a callback parameter that is invoked when the method is complete.

Again, the reason for this is that the data access code will most likely invoke an asynchronous

SOAP or REST service, and so the object factory methods must also be asynchronous. Here’s an

example of a factory type for Silverlight or WP7:

public class PersonFactory : ObjectFactory

{

public void Fetch(

int id, Csla.DataPortalClient.LocalProxy<PersonEdit>.CompletedHandler handler)

{

try

{

var result = new PersonEdit();

// implement DAL code here (factory implementation)

// or invoke external DAL here (factory invoke)

MarkOld(result);

handler(result, null);

}

catch (Exception ex)

{

handler(null, ex);

}

The callback handler is invoked to tell the data portal when the method is complete, and that is

how the result is returned to the data portal.

It is critical that the callback handler be invoked whether an exception occurs or not.

If the callback handler isn’t invoked the data portal will not know that the method

has completed.

If the code does invoke an asynchronous service or behavior, the callback handler should be

invoked when the asynchronous operation is complete.

Data Portal Model Overview

At this point I will revisit all four models with a focus on the role of the data access invocation

concept and the impact of each model on the business object.

Throughout this discussion you should be aware that the client-side data portal functionality is

the same for all four models. The selection of model only affects the implementation of server-side

code.

Using CSLA 4: Data Access Page 9

Rev 1.0

Remember that when talking about the data portal, “server-side code” is a logical concept, and

the “server-side code” will run on the client machine in a 1- or 2-tier physical deployment. Please

refer to the Using CSLA 4: CSLA .NET Overview ebook for more details.

The four models are listed in Table 1.

Model Name

Data portal

invokes

DAL location

Description

Result

Encapsulated

Invocation

Business

object

Separate

DAL

assembly

The data portal creates

the business object and

invokes methods on that

object; the business object

then invokes the DAL to

persist its data

Encapsulation preserved

Metastate auto-managed

Clear DAL separation

Medium complexity

Factory

Implementation

Factory object

In factory

class

The data portal creates

the factory object and

invokes methods on that

object; the factory object

then creates the business

object and implements the

DAL directly in the factory

class

Encapsulation violated

Metastate handled

manually

Clear DAL separation

Medium complexity

Factory

Invocation

Factory object

Separate

DAL

assembly

The data portal creates

the factory object and

invokes methods on that

object; the factory object

then creates the business

object and invokes the

DAL to persist the data

Encapsulation violated

Metastate handled

manually

Clear DAL separation

High complexity

Encapsulated

Implementation

Business

object

In business

class

The data portal creates

the business object and

invokes methods on that

object; the business object

implements the DAL

directly in the business

class

Encapsulation preserved

Metastate handled auto-

managed

No DAL separation

Low complexity

Table 1. Data access models supported by the data portal

I’ve listed the items in Table 1 in order of my preference. The first two are the best options for

most applications. The third has more layers of abstraction than is necessary. The fourth is the

simplest, but doesn’t allow for a clearly separated Data Access layer.

I will discuss each model in more detail, but first I will expand on the results or outcomes you can

expect from each model. As you can see from the right-most column in Table 1, there are four

important outcomes or results you can expect depending on which data portal model you choose.

剩余215页未读，继续阅读

jade_shanes

粉丝: 0
资源: 3

使用CSLA .NET 4进行数据访问

Towards-a-Side-Access-Free-Data-Grid-Resource-by._Free!

Machine-Learning-Data-Access

access-wi-fi-data-android:在 Android 中访问 Wi-Fi 数据

Scavis.com-DataAccess-开源

Smart Data Access - Data Visualization in SAP HANA.zip

Python库 | scikit-dataaccess-1.9.17.post1.tar.gz

Data-Object-Access-:一个有用的脚本

IBatis.net-IBatis.DataAccess.1.9.2/IBatis.DataMapper.1.6.2

ars-dataaccess:MSSQL和Mongo数据访问抽象

OPC Data Access Wrapper Class-开源

最新资源