在浏览网站的时候，我们经常会提交一些信息，这些信息也被叫做“表单”，“提交信息”专业一点的叫法是“提交表单”。 通常会提交的信息就是注册信息，登录信息，登陆之后还需要提交详细的个人信息，其中就会包括学历，地址，项目经验等等。 还有就是在电商网站，我们还会提交订单，添加收藏，添加购物车。 在网络中，我们每天都会遇到各种各样的表单，随着网络的普及，信息化的普及，很多信息都是通过网络提交的，我们会频繁的和表单打交道。 那么什么是表单呢？ 表单指的是用户在页面中填写的信息的总和，也是填写的信息项的总和。 本文是从设计者的角度看动态表单的设计。
今天给大家分享的是： 用户管理模块，或者说用户管理子系统如何设计，包括如何抽象以及相关的存储。 大部分的应用中都会有用户的概念，除非你的网站全部是匿名访问，不保存用户任何信息。其实这也是不好的，因为你的网站如果没有用户的概念，没有设计用户模块，就很难收集用户信息及用户行为，也就很难有数据来分析用户的喜好，也就少了一条给用户提供更好服务的途径。 现在是web2.0的时代，甚至是web3.0，用户越来越在意网站给自己带来的内容，显示的内容是否合适自己，而且用户很想参与网站的内容构建，想要对自己构建的内容进行聚合、管理。 说了这么多，就是要说明用户管理模块很重要，是个应用就应该考虑，而且还是重中之重。
业务层引入缓存组件实现业务对象的缓存，对外部应该是个黑盒，不需要外部关心使用那种缓存组件，使用的具体细节，哪些场景使用，外部存取业务对象的接口也不应该发生变化，不需要任何缓存相关参数。但是应该允许外部调用者关闭缓存，就是说外部调用者应该可以在初始化业务对象的时候声明不使用业务对象的缓存机制，或者在使用的过程中设置关闭和开启业务对象的缓存机制。 假设我是业务层的调用者，我希望在初始化业务层对象的时候，可以设置是否启用业务对象的缓存机制。同时在使用已经初始化的业务层对象的时候，也可以在需要的时候进行缓存机制的开启和关闭。
设计模式-规约模式C#版
最近突然对网站的用户关系感起了兴趣。当然了，万事万物都是有原因的，只是有的是直接原因，有的是间接原因；有的原因很明显，有的原因不明显；有的原因很容易说清楚，有的原因说不明白。总之一句话，肯定是原因的。 引发这个系列话题的原因是，在我收到的人人或者是校内发送的的推荐关注邮件中，或者是各大微博、SNS社区中的推荐关注与推荐话题中，发现大多和我没有关系，推荐的准确率不是很高，甚至可以说的比较低，更有甚者，还有一些毫无相关的人和内容推荐过来，我就不明白了，既然没有就算了吧，为什么非要有呢？
项目是一个互联网应用。 假设项目有不同的用户群体，每个用户群体的前端都是一个独立的项目，交给不同的开发人员进行开发，前端和后端的交互方式选择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（数据访问层）。文中提出的观点也都是个人的一点认识，与任何组织没有关系，如有异议，还请各位踊跃拍砖。 当然了，出现的这些问题，也可能只是我个人的问题，不代表每
引言 今天给大家介绍的是ORM中的有选择持久化技术。现在的很多ORM工具都支持有选择的持久化，就是对于属性有选择的持久化。也可以理解为只持久化那些有变化的属性，忽略没有变化的属性。 正文 很多时候我们想要知道实体的那些属性被更新，那些属性没有变化。 在很多的ORM工具中，在持久化数据的时候，可以判断哪些属性有值，哪些属性被更新过，这样的属性才会被持久化，
引言 本文中将向大家介绍我对于是使用实体的一些体验，欢迎大家拍砖。更欢迎提出不同或者相同的意见。 正文 刚开始学会使用实体的时候就是建立一个Entity类库，然后里面的实体被其他各层引用。大家传递和使用的都是这一个类库中的实体，包括前端和后台的项目都是引用这个类库，传递和操作这个类库中的实体。
今天和大家谈的是我对于实体的一些认识，难免有偏颇之初，还请各位指出。 大家都看到标题中的三个英文缩写了：DTO,DMO,DPO。DTO大家应该还是熟悉的，Data Transfer Ojbect（数据传输对象）。研究过DDD（Domain Driven Design领域驱动设计）的人应该了解过DTO。是用来传输数据的对象，应为领域对象虽然有数据（属性），但是领域对象上面还带有操作
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
