设计一个系统内部结算消费的币种，然后充值的钱和这个币种有某种规则匹配，比如说1:1，或者是1:5之类的比例，这样的话，就可以轻松解决充值返利的需求，而且顺便还可以解决多国货币的需求，因为我们系统内部消费结算使用统一的平台币，然后外部的任何币种都根据匹配规则换算成平台币来计算。不管是充值，还是消费，还是返利，还是结算，都是用统一的平台币，当然了，平台币对用户是透明的，最终用户看到的是自己的币种。甚至用户也可以有多种币种，都没有关系的，反正平台内部使用的是统一的平台币。
在浏览网站的时候，我们经常会提交一些信息，这些信息也被叫做“表单”，“提交信息”专业一点的叫法是“提交表单”。 通常会提交的信息就是注册信息，登录信息，登陆之后还需要提交详细的个人信息，其中就会包括学历，地址，项目经验等等。 还有就是在电商网站，我们还会提交订单，添加收藏，添加购物车。 在网络中，我们每天都会遇到各种各样的表单，随着网络的普及，信息化的普及，很多信息都是通过网络提交的，我们会频繁的和表单打交道。 那么什么是表单呢？ 表单指的是用户在页面中填写的信息的总和，也是填写的信息项的总和。 本文是从设计者的角度看动态表单的设计。
从简单二进制到相对路径，再到图片服务器，再到分布式路径无关。
动态表单数据库设计
需求分析的过程以及一些常用的方法及工具。
手机短信在系统的应用中越来越广泛，从单纯的发送信息到手机，发展到接收手机发送的短信，进行信息的获取，更有甚者，还可以进行业务的变更，业务数据的修改。从少量的发送，发展到大量的收发，衍生出大量的互动性短信。这就对短信收发的设计提出了更高的要求，不仅仅是简单的发送消息，不仅仅是简单的短信模块，而且需要配合消息队列，短信路由子系统，业务编码规则等等技术来满足大量互动性短息的收发要求。
今天给大家分享的是： 用户管理模块，或者说用户管理子系统如何设计，包括如何抽象以及相关的存储。 大部分的应用中都会有用户的概念，除非你的网站全部是匿名访问，不保存用户任何信息。其实这也是不好的，因为你的网站如果没有用户的概念，没有设计用户模块，就很难收集用户信息及用户行为，也就很难有数据来分析用户的喜好，也就少了一条给用户提供更好服务的途径。 现在是web2.0的时代，甚至是web3.0，用户越来越在意网站给自己带来的内容，显示的内容是否合适自己，而且用户很想参与网站的内容构建，想要对自己构建的内容进行聚合、管理。 说了这么多，就是要说明用户管理模块很重要，是个应用就应该考虑，而且还是重中之重。
业务层引入缓存组件实现业务对象的缓存，对外部应该是个黑盒，不需要外部关心使用那种缓存组件，使用的具体细节，哪些场景使用，外部存取业务对象的接口也不应该发生变化，不需要任何缓存相关参数。但是应该允许外部调用者关闭缓存，就是说外部调用者应该可以在初始化业务对象的时候声明不使用业务对象的缓存机制，或者在使用的过程中设置关闭和开启业务对象的缓存机制。 假设我是业务层的调用者，我希望在初始化业务层对象的时候，可以设置是否启用业务对象的缓存机制。同时在使用已经初始化的业务层对象的时候，也可以在需要的时候进行缓存机制的开启和关闭。
现在的手机上网已经很普及，尤其是智能手机，在一些稍大的城市，几乎是满天飞了，在一些中小城市，普及的也比较广。在我国，手机上网用户，已经快达到4亿，可见市场是多么的诱人。 智能手机常见的操作系统有：android，apple os，windows phone，还有以前的symbian，smart phone等。 而且，这两年又加入了一种新的客户端，那就是pad。pad相比较手机而言，屏幕更大，7寸，8寸，10寸，存储空间更大，甚至处理能力更强。 pad的操作系统主要是两种：android和apple os。 手机和pad上网一般都支持手机卡上网，或者是无线连接上网。 所以现在的网站，有相当一部分在建立的时候，就考虑要支持手机浏览。就算是已经建立好的网站，很多也开始考虑加入对手机浏览的支持。更有一些，同时还做了手机客户端，充分利用手机的资源，提供更进一步的服务。
本文主要针对条件处理中的if分支，进行了一种方式的重构。将流水线的场景引入到if处理流程中，针对一个对象的各种if分支处理的时候就可以套用这个改进后的流程。可以得到下面的一些好处： 1.上面代码中的获取订单方法，不会越来越长，这样阅读起来就很好理解，在后面进行维护的时候，就很容易来做了。 2.添加一个新的条件处理分支也很容易，只要把这种条件处理看做是一个闸门，在处理流水线中加入新闸门就可以了，其他的都不需要变化。 3.调整原来的条件处理，也只需要修改闸门内部的处理代码即可，不用担心是否影响其他处理分支。 4.分支独立之后，还可以针对每个分支做单元测试。
本文由ruby-china的一篇帖子“由小数的精度问题引出设计问题”引出，帖子也是我发的，在查看回复的时候学到了不少内容，有了一点感悟，所以就想总结一下。 首先声明本文选用的编程语言为ruby，运行环境是ubuntu。 在编写财务，电子商务之类应用的时候，经常会碰到小数，小数乘、除、加、减的场景。 大多数语言表示小数，都有单精度float，双精度double，还有一个更加精确的decimal，无论是哪一种，都统称为浮点数。 浮点数是一个近似的数值，不是精确的数值。至于为什么不精确，这个涉及到操作系统的底层，和二进制的保存有关。 这就造成了浮点数的比较结果，有时会出现违反生活常识的场景。文中将介绍两个大家常用的解决办法，以及引出来的系统设计问题。
设计模式-规约模式C#版
设计模式-策略模式C#版
大概的思路是这样的： 这类信息其实可以大量的缓存，在后台更新产品的同时，更新对应的缓存。前台访问的时候，先从缓存里面获取，如果没有再从物理存储中读取。 使用分布式缓存，集中管理缓存的存取，使得前台的集群都可以访问缓存，提高缓存的命中率。 还需要较好的处理缓存的失效，还需要注意缓存的大面积失效导致的大量访问直接请求物理存储，导致IO出现瓶颈。 还会需要一个缓存监测系统，随时监测缓存的运行情况。
最近突然对网站的用户关系感起了兴趣。当然了，万事万物都是有原因的，只是有的是直接原因，有的是间接原因；有的原因很明显，有的原因不明显；有的原因很容易说清楚，有的原因说不明白。总之一句话，肯定是原因的。 引发这个系列话题的原因是，在我收到的人人或者是校内发送的的推荐关注邮件中，或者是各大微博、SNS社区中的推荐关注与推荐话题中，发现大多和我没有关系，推荐的准确率不是很高，甚至可以说的比较低，更有甚者，还有一些毫无相关的人和内容推荐过来，我就不明白了，既然没有就算了吧，为什么非要有呢？
随着平台做大做强，很可能会走向定制操作系统，定制数据库，甚至定制硬件，定制任何可以定制的东西这样一条路。 在服务器、架构、组件等技术选择方面，主要有两个方向：1选择成熟商用。2选择开源+自主研发
三者的目的都是分离关注，使得UI更容易变换（从Winform变为Webform），使得UI更容易进行单元测试。
项目是一个互联网应用。 假设项目有不同的用户群体，每个用户群体的前端都是一个独立的项目，交给不同的开发人员进行开发，前端和后端的交互方式选择WebService。 在前端和后端交互的过程中，主要有两类操作：一类是查询，包括返回单个记录和返回集合两种类型的查询；一类是命令，包括添加、删除、更新，当然，一次操作也可能是几个命令的组合请求。
1引言 在标题的取名上，不敢说颇费心机，也算得上花费了一点功夫的。首先想到的是“架构设计过程”，又觉得是不是太大了，因为例子比较局部，不是很完整。叫做“结构变化过程”可能更好点。但是又怕名字取的小气了，进来的人少，参与讨论的就更少了，最终还是取了这个有点忽悠人的标题“架构演进”。 今天的这个架构演进，使用系统中一个局部的实例进行推导和演进，一起来观察一下，架构是如何不满足需求的？架构如何
引言 最近两个星期在研究android的应用开发，学习了android应用开发的基础知识，基本控件，基本布局，基本动画效果，数据存储，http访问internet等等基础知识。 android中有一个概念，叫做activity。什么叫做activity呢？中文译为【活动】。我觉得类比到我们.NET里面的话，就好比是WinForm中的Form窗体，或者是ASP.NET中的Pa
1 引言 今天发现了伍迷的《大话数据结构》系列，应该不错，从第一篇开始阅读。因为之前就阅读过他的《大话设计模式》，觉得通俗易懂，而且从浅入深，结合实际情况，是一本不可多得的好书。 读到《《大话数据结构》第1章 数据结构绪论 1.2 你数据结构怎么学的？》这篇的时候，就出现了一个小的场景。他的学生小菜在工作中被分配了一个任务，完成一个客户排队模块的代码。小菜就建立一张表，保存每次的
1 引言 DDD，全名：Domain Driven Design，中文名：领域驱动设计。 2 DDD的分层 分层的架构方式是我们常用的，这里的分层是说n-layer，指的是逻辑的分层，目的是分离职责。常用的是三层：表现层，业务逻辑层，数据访问层。 DDD把原来经典三层（表现层，业务逻辑层，数据访问层）中的业务逻辑层又细分为两层：应用层和领域层。应用层负责领域对象的协调和调度
引言 本文提到的分层只是软件架构上的分层。文中的传统分层指的是传统的三层结构：UI（界面表现层）,BLL（业务逻辑层）,DAL（数据访问层）。文中提出的观点也都是个人的一点认识，与任何组织没有关系，如有异议，还请各位踊跃拍砖。 当然了，出现的这些问题，也可能只是我个人的问题，不代表每
引言 本篇给大家介绍我这个工具的雏形结构，以及基本的用法，还请大家多提意见。 初看起来，这个有点像NHibernate。说到这里，肯定有人要拍砖了。其实，我也知道。我这个不入流的东西，和NHibernate相比差远了。我开发这个东西的原因主要有两个： 1）NHibernate太复杂了，学习了两个星期，觉得它太强大了。但是强大是用复杂做代价的，里面要学习的东西太多了
我不知道NH的ORM具体如何实现的，我的想法就是通过字段名称和属性名称的对应关系来实现赋值。 简单的类型比较好做，直接赋值就可以了。简单类型是说int，string之类的。 有几个需要注意的地方： 1 属性的类型是另外一个类 2 属性是一个集合 3 类有两个属性的类型是同一个类，例如：种子有用量及其单位，和产量及其单位，用量的单位和产量的单位是一个类型 4 属性
引言 今天给大家介绍的是ORM中的有选择持久化技术。现在的很多ORM工具都支持有选择的持久化，就是对于属性有选择的持久化。也可以理解为只持久化那些有变化的属性，忽略没有变化的属性。 正文 很多时候我们想要知道实体的那些属性被更新，那些属性没有变化。 在很多的ORM工具中，在持久化数据的时候，可以判断哪些属性有值，哪些属性被更新过，这样的属性才会被持久化，
引言 本文中将向大家介绍我对于是使用实体的一些体验，欢迎大家拍砖。更欢迎提出不同或者相同的意见。 正文 刚开始学会使用实体的时候就是建立一个Entity类库，然后里面的实体被其他各层引用。大家传递和使用的都是这一个类库中的实体，包括前端和后台的项目都是引用这个类库，传递和操作这个类库中的实体。
1 业务描述 首先我们来认识一下通告，消息，提醒这三者的区别和联系。 1.1 通告Bulletin： 平台发，用户收。分为实时通告和非实时通告。通告有优先级：紧急，高，普通。 平台向单个用户发，平台向多个用户发，平台向某一个用户类型发，平台向全部用户发。 平台发布通告。 平台撤销通告。 平台删除通告。 平台查询通告。 用户查看通告。 用户查询通告。 数据库特点 一般不修改，
今天和大家谈的是我对于实体的一些认识，难免有偏颇之初，还请各位指出。 大家都看到标题中的三个英文缩写了：DTO,DMO,DPO。DTO大家应该还是熟悉的，Data Transfer Ojbect（数据传输对象）。研究过DDD（Domain Driven Design领域驱动设计）的人应该了解过DTO。是用来传输数据的对象，应为领域对象虽然有数据（属性），但是领域对象上面还带有操作
MVC改变了我们设计应用的方式和角度。之前我们从模块、数据库的角度分析设计应用，MVC使得我们从url、用户请求角度分析设计应用，更加贴近用户。
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
