Application Architecture Guide 2.0 - CH 19 - Mobile Applications(3)

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
日志服务 SLS,月写入数据量 50GB 1个月
简介:

本文翻译Data Access Debugging Device Exception Management Logging部分。

 

Data Access

Data access on a mobile device is constrained by unreliable network connections and the hardware constraints of the device itself. When designing data access, consider how low bandwidth, high latency, and intermittent connectivity will impact your design.

数据存取

移动设备上的数据存取受不可靠的网络连接和设备本身硬件的限制。因此,在设计数据存取策略的时候,要考虑低带宽、高延时和间歇性网络连接的影响。

 

Consider the following guidelines when designing data access:

 Program for data integrity. Files left open during device suspend and power failures may cause data-integrity issues, especially when data is stored on a removable storage device.

 Include exception handling and retry logic to ensure that file operations succeed.

 Do not assume that removable storage will always be available, as a user can remove it at any time. Check for the existence of a removable storage device before writing or using FlushFileBuffers.

 If you need to ensure data integrity in case the device loses power or has connectivity disruptions, considering using transactions with SQL Server Mobile.

 If your application must access a disconnected database, consider using the device database services (such as SQL Server Compact Edition).

 If you use XML to store or transfer data, consider its overall size and impact on performance. XML increases both bandwidth and local storage requirements. Use compression algorithms or a non-XML transfer method.

 Consider the use of custom objects instead of DataSets to reduce memory overhead and improve performance.

 If your application needs to sync with multiple database types, use Sync Services for ADO.NET. It allows you to store data in Microsoft SQL Server, Oracle, or DB2.

在设计数据存取策略时,考虑以下指导方针:

•数据完整性设计。在设备暂停或者断电时,仍将文件处于打开状态,那样可能会引起数据完整性的问题,特别是当数据存储在可移动的存储设备上时。

为了确保文件的成功操作,要加入异常和重试逻辑处理。

由于用户可能随时插拔可移动存储,因此不要认为它是永远可用的。在写操作或者使用FlushFileBuffer之前,检查可移动存储是否存在。

在设备掉电或者连接丢失的情况下,要确保数据完整性,则可以考虑使用SQL Server Mobile的事务。

如果应用程序必须使用非在线的数据库,那么考虑使用设备数据库服务(例如SQL Server Compact Edition)。

•如果使用XML来存储或者传递数据,那么考虑它的总体大小和对性能的影响。因为XML会同时增大带宽和本地存储的需求。解决方法是考虑使用压缩算法或者使用非XML传递方法。

•考虑使用自定义对象来代替DataSets,这样可以减小内存开销,提高系统性能。

•如果需要和多种数据库同步,那么就使用ADO.NETSync服务。它允许应用程序将数据存储于Microsoft SQL ServerOracleDB2数据库中。

 

Debugging

Mobile application debugging can be much more expensive than debugging a similar application on a PC. Consider this debugging cost when deciding which devices, and how many devices, your application will support. Also keep in mind that it can be harder to get debug information from the device, and that device emulators do not always perfectly simulate the device hardware environment.

调试

与类似的PC上的应用程序调试相比,移动设备上的调试可能会更加昂贵。在决定应用程序支持的设备种类和数量的时候,要考虑这个调试成本。同时,从设备获得调试信息是很难的,而且设备模拟器也不能完全模拟设备的硬件环境,这点必须牢记。

 

Consider the following guidelines when designing your debugging strategy:

 Understand your debugging costs when choosing which devices to support. Factor in tools support, the cost of initial (and perhaps replacement) test devices, and the cost of software based device emulators.

 If you have the device you are targeting, debug your code on the actual device rather than on an emulator.

 If the device is not available, use an emulator for initial testing and debugging. Consider that an emulator might run code slower than the actual device. As soon as you obtain the device, switch to running code on the device connected to a normal PC. Perform final testing on your device when not connected to a PC. Add in temporary or permanent mechanisms to debug problems in this scenario. Consider the needs of people who will support the device.

 Test scenarios where your device is fully disconnected from any network or connection, including a PC debugging session.

 If you are an OEM or ODM and your device has not yet been created, note that it is possible to debug a mobile program on a dedicated x86-based Microsoft Windows® CE PC. Consider this option until your device is available.

在设计调试策略时,考虑以下指导方针:

•在选择支持的设备时,了解程序调试的成本。包括工具支持、初始(替代)测试设备花费和基于软件的模拟器花费等因素。

如果手头有目标设备,那么尽量在真实设备上调试代码,而非在模拟器上调试。

•如果手头没有目标设备,那么就使用模拟器来进行初始的调试和测试。与真实设备相比,模拟器的运行速度可能要慢一些。一旦得到真实设备,就将设备连接到PC上,然后调试代码。在调试最终代码的时候,将设备和PC机脱离。在这种场景下,增加暂时或者永久的机制来调试出现的问题。考虑那些使用设备的用户的需求。

在设备和网络或者连接完全断开的情况下测试应用程序,也包括和PC机断开的情况。

•如果您是OEM或者是ODM,而且设备尚未定型,那么就考虑在专门的基于x86架构的Microsoft Windows® CE设备上调试的情况。在设备成型以前,都必须考虑这种情况。

 

Device

Mobile device design and development is unique in that you may be targeting multiple devices with very different hardware parameters. Keep the heterogeneous device environment in mind when designing your mobile application. Factors include variations in screen size and orientation, limitations in memory and storage space, and network bandwidth and connectivity. Your choice of a mobile operating system will generally depend on the target device type.

设备

由于最终的硬件参数的差异,移动设备的设计和开发可以说是独一无二的。在设计移动应用程序时,必须牢记设备环境的差异性。这些因素包括屏幕大小和方向的不同,内存和存储空间的限制,以及网络带宽和连接性的差异。移动设备上操作系统的选择一般是基于目标设备类型的。

 

Consider the following guidelines when determining your device strategy:

 Optimize the application for the device by considering factors such as screen size and orientation, network bandwidth, memory storage space, processor performance, and other hardware capabilities.

 Consider device-specific that you can use to enhance your application functionality, such as accelerometers, graphics processing units (GPUs), global positioning systems (GPS), haptic (touch, force and vibration) feedback, compass, camera, and fingerprint readers.

 If you are developing for more than one device, design first for the subset of functionality that exists on all of the devices, and then customize for device-specific features when they are detected.

 Create modular code to allow easy module removal from executables. This covers cases where separate smaller executable files are required due to device memory-size constraints.

在决定设备策略时,考虑以下指导方针:

从屏幕大小和方向,网络带宽,内存大小,处理器性能和其他硬件参数等方面来为您的设备进行应用程序优化。

•考虑使用设备特有的硬件来增强应用程序的功能,比如加速器、图形处理单元、全球定位系统、触觉反馈(触摸、应力和震动)、指南针、摄像头和指纹采集等等。

如果你的设计面向多种设备,那么就先设计能够在所有设备上实现的功能子集。然后再根据特定的设备来定制特定的功能。

•创建模块化的代码,这样可以使以后的移除操作变得轻松。由于设备内存大小的限制,可以将大文件分割成更加小的可执行文件。

 

Exception Management

Designing an effective exception-management strategy is important for the security and reliability of your application. Good exception handling in your mobile application prevents sensitive exception details from being revealed to the user, improves application robustness, and helps to avoid your application being left in an inconsistent state in the event of an error.

Consider the following guidelines when designing for exception management:

 Design your application to recover to a known good state after an exception occurs.

 Do not use exceptions to control logic flow.

 Do not catch exceptions unless you can handle them.

 Design a global error handler to catch unhandled exceptions.

 Design an appropriate logging and notification strategy that does not reveal sensitive information for critical errors and exceptions.

异常管理

对于应用程序的安全性和可靠性来说,设计一个有效的异常管理策略是非常重要的。优秀的异常处理防止将敏感异常信息暴露给用户,提供程序的鲁棒性,在出错事件中,避免应用程序处于不一致的状态。

在设计异常管理策略时,考虑以下指导方针:

•在异常发生后,应用程序要能够恢复到一个已知的正常状态。

不要利用异常来控制程序的逻辑流程。

不要捕捉异常,除非你能够处理他们。

设计一个全局的错误处理来捕捉不能处理的异常。

•设计一个合理的日志和消息提醒策略,不至于暴露重要错误和异常的敏感信息。

 

Logging

Because of the limited memory on mobile devices, logging and instrumentation should be limited to only the most necessary cases; for example, attempted intrusion into the device. When devices are designed to be a part of a larger infrastructure, choose to track most device activity at the infrastructure level. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access, and by the same routines that access the resource. Consider the fact that some of the logs might have to be generated on the device and must be synchronized with the server during periods of network connectivity.

日志

由于移动设备内存的限制,应该只在必须的情况下做日志和记录。例如,企图入侵设备。当设备被设计为一个大的基础架构中的一部分时,那么要在基础架构这一层追踪大部分设备的活动。如果在资源获取时进行审查,那么这个举动一般被认为是最具有权威性的。考虑那些日志必须产生在设备上的情况,在网络可连接时,将它们同步到服务器上。

 

Consider the following guidelines when designing logging:

 If you carry out extensive logging on the device, consider logging in an abbreviated or compressed format to minimize memory and storage impact. There is no system Event Log in Windows Mobile.

 If you do not require extensive logging, consider using OpenNetCF on the device. Be aware that OpenNetCF relies upon XML and will take up more space than a simple binary logging model.

 Consider using platform features such as health monitoring on the server, and mobile device services on the device, to log and audit events.

 Synchronize between the mobile database logs and the server database logs to maintain audit capabilities on the server. If you have an Active Directory infrastructure, consider using the System Center Mobile Device Manager to extract logs from mobile devices. See the Tchnology Considerations section for requirements for the Mobile Device Manager.

 Do not store sensitive information in log files.

 Decide what constitutes unusual or suspicious activity on a device, and log information based on these scenarios.

在日志时,考虑以下指导方针:

如果你在设备上执行广泛的日志策略,那么考虑使用小型的或者压缩的文件格式来减小存储空间的需求。Windows Mobile上没有系统事件日志。

如果你不需要广泛的日志策略,那就考虑使用OpenNetCF。需要注意的是,OpenNetCF是基于XML的,它比简单的二进制日志模型占用更多的存储空间。

考虑使用平台特性来记录并审核事件,例如服务器上的health monitoring,设备上的mobile device services

•将设备数据库日志和服务器数据库保持同步,以维持服务器端的审核能力。如果你有Active Directory基础架构,那么就考虑使用System Center Mobile Device Manager来从移动设备上提取日志。请参考Technology Considerations节中关于Mobile Device Manager需求的部分。

不要在日志文件中记录敏感信息。

•考虑哪些构成了设备上的异常活动或者可疑活动,记录这些场景的日志。




本文转自施炯博客园博客,原文链接:http://www.cnblogs.com/dearsj001/archive/2009/01/15/1376422.html,如需转载请自行联系原作者

相关文章
|
5月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
58 6
|
5月前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
39 2
|
5月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
49 0
|
5月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
53 0
|
5月前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
59 0
|
5月前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
53 0