关系逻辑

小孩子就喜欢问什么是爱情,可是大人们也不知道 用户界面表示层(UI) 业务逻辑层(BLL) 数据访问层(DAL) 所谓的三层架构,是小白们最流行讨论的话题,以为自己很专业,其实就是很专业,专业到没有人解释得清楚. 那什么是三层呢? 今天你三层了吗? 我见过很多小白,喜欢在代码中写3个项目文件(或者3个文件夹),命名为MODEL, BLL和DAL, DAL里是TSQL与SP, BLL完全只是调用单个DAL方法,例如 CLASS BLL ShowProducts() { DAL.GetProducts(); } 以此类推, 完全是为了三层而三层,并不知道为什么要三层.并不是我给自己儿子起名字叫主席,就可以入主中南海.名字只是个代号. 我不知道这样的BLL是在搞什么. 所谓BLL,它的作用是,,根据用户的某个指令,遵守我们业务所制定的规则,执行流程的作用, 将DAL中所返回的实体进行有机的联系与约束, 然后 或者保存或者展现给用户. 而一个程序,远远不止三层,比如 将结果序列化成json或者xml,(用于ajax或者与webservice通信,或者作为webservice) 依赖注入的IOC容器(用于对象共享与持久化) 即将登上历史舞台的Entity Framework 他们都是抛开业务逻辑,而又不参与TSQL,(Entity Framework是将通用的Entity

3 月，跳不动了？>>> 一、前言 随着美团外卖业务的不断迭代与发展，外卖用户数量也在高速地增长。在这个过程中，外卖营销发挥了“中流砥柱”的作用，因为用户的快速增长离不开高效的营销策略。而由于市场环境和业务环境的多变，营销策略往往是复杂多变的，营销技术团队作为营销业务的支持部门，就需要快速高效地响应营销策略变更带来的需求变动。因此，设计并实现易于扩展和维护的营销系统，是美团外卖营销技术团队不懈追求的目标和必修的基本功。 本文通过自顶向下的方式，来介绍设计模式如何帮助我们构建一套易扩展、易维护的营销系统。本文会首先介绍设计模式与领域驱动设计（Domain-Driven Design，以下简称为DDD）之间的关系，然后再阐述外卖营销业务引入业务中用到的设计模式以及其具体实践案例。 二、设计模式与领域驱动设计 设计一个营销系统，我们通常的做法是采用自顶向下的方式来解构业务，为此我们引入了DDD。从战略层面上讲，DDD能够指导我们完成从问题空间到解决方案的剖析，将业务需求映射为领域上下文以及上下文间的映射关系。从战术层面上，DDD能够细化领域上下文，并形成有效的、细化的领域模型来指导工程实践。建立领域模型的一个关键意义在于，能够确保不断扩展和变化的需求在领域模型内不断地演进和发展，而不至于出现模型的腐化和领域逻辑的外溢。关于DDD的实践，大家可以参考此前美团技术团队推出的《

哪些东西应该放在reducer里面 不要复杂化ruducer 只有需要共享的才放进去 域数据 1：不要复杂化reducer 是指 不要所有的东西都放在redux里面 2：根据第一条，只有多个组件用到的数据才需要放入 redux里面，有的人 会说，把组件的ui状态放入redux 是方便管理，我认为 如果你需要在另外一个组件控制这个组件，那把这个组件的ui状态放入state自然是可以的，这遵循只有共享的数据才放入redux的原则，但是 一股脑的把所有的ui状态都放进去 只会增加redux的复杂性很很多不必要的代码 3:域数据，与ui状态相比，域数据被多个组件共同访问的几率要大大高于组件内部ui状态，所以 域数据应该放入redux reducer如何调用其他reducer数据？ 像id关联查询这些，或者数据库中的多表关联查询，和多表批量操作，这些在redux中如何实现？ redux希望我们以关系型数据的方式设计state，但是如果以关系型数据库的方式设计state，那就涉及到 多个reducer的并处理和顺序处理。但是reducer要求是纯函数，很显然 我们不可能在函数里面 去调用其他reducer，所以 唯一的操作路径 就是在容器组件里面 拿到其他reducer的数据，然后放入action中。至于并处理，则可以通过多个reducer响应一个action来做到。 业务逻辑在哪里？

原文地址： http://www.work100.net/training/monolithic-frameworks-spring.html 更多教程： 光束云 - 免费课程 Spring 序号 文内章节 视频 1 概述 - 2 体系结构 - 3 特点 - 4 Spring与IoC - 5 第一个Spring应用程序 - 请参照如上 章节导航 进行阅读 1.概述 Spring 的主要作用就是为代码“ 解耦 ”，降低代码间的耦合度。 根据功能的不同，可以将一个系统中的代码分为 主业务逻辑 与 系统级业务逻辑 两类，它们各自具有鲜明的特点： 主业务代码间逻辑联系紧密，有具体的专业业务应用场景，复用性相对较低； 系统级业务相对功能独立，没有具体的专业业务应用场景，主要是为主业务提供系统级服务，如日志、安全、事务等，复用性强。 Spring 根据代码的功能特点，将降低耦合度的方式分为了两类： IoC 与 AOP 。 IoC 使得主业务在相互调用过程中，不用再自己维护关系了，即不用再自己创建要使用的对象了。而是由 Spring 容器统一管理，自动“注入”。 而 AOP 使得系统级服务得到了最大复用，且不用再由程序员手工将系统级服务“混杂”到主业务逻辑中了，而是由 Spring 容器统一完成“织入”。 Spring 是于 2003 年兴起的一个轻量级的 Java 开发框架

转自： 平凡希 老师 https://www.cnblogs.com/xiaoxi/ SpringMVC的工作原理图： SpringMVC流程 1、 用户发送请求至前端控制器DispatcherServlet。 2、 DispatcherServlet收到请求调用HandlerMapping处理器映射器。 3、 处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。 4、 DispatcherServlet调用HandlerAdapter处理器适配器。 5、 HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。 6、 Controller执行完成返回ModelAndView。 7、 HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。 8、 DispatcherServlet将ModelAndView传给ViewReslover视图解析器。 9、 ViewReslover解析后返回具体View。 10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。 11、 DispatcherServlet响应用户。 组件说明：

废话少说，直接上工程目录 对应的UML图 代码： package com.waibizi; /** * 说明：是整体与部分的关系，但部分不能脱离整体而独立存在。逻辑上能用"has a"表示。 * * 代码体现：成员变量。 * @author 歪鼻子 * */ @SuppressWarnings("all") public class Computer { private Mouse mouse = new Mouse(); private Moniter moniter = new Moniter(); public Mouse getMouse() { return mouse; } public void setMouse(Mouse mouse) { this.mouse = mouse; } public Moniter getMoniter() { return moniter; } public void setMoniter(Moniter moniter) { this.moniter = moniter; } } 来源： https://www.cnblogs.com/waibizi/p/12078865.html

这里说的网络特征是指 ESRI 所提倡的几何网络结构中的特征，其与网络要素的关系就是几何网络与逻辑网络的关系。 字串7 在进行建模时（如geodatabase），几何网络从地理视角来建立表，如公路表、城市表、铁路表等。而逻辑网络需要3张表：边要素表、接合要素表和连接表（描述前两者是如何连接的）。边要素表和接合要素表将提供要素的唯一标识的要素ID。关于边和接合的概念，可参考ESRI在线帮助。 字串9 一、网络特征的成员构成 字串1 几何网络中的特征主要有四种：简单边、简单接合、复杂边和复杂接合。(边：edge，接合：junction) 字串1 1、一个简单边（特征层面）与逻辑网络中的 GPS 一个独立边（要素层面，没有地理概念和几何坐标）相关联，即一对一的关系。 2、一个简单集合与逻辑网络中的一个单独的节点相关联，也是一对一的关系。 3、一个复杂边特征可与逻辑网络中的任意数目的边相关联，这些边必须组织在一个链结构中。（如：junction1-edge1-junction2-edge2-junction3-edge3-junction4，很显然，他们并不一定在一条直线上） 4、一个复杂接合特征与逻辑网络中接合与边的群相关联。这些边与接合相互连接，可被组织到任何拓扑结构中。从抽象与具体的角度讲，即把这样一个小网络抽象为一个独立接合来看待，成为实质意义上的一个内部网络

三、OVN入门 3.1 OVN简介 Open vSwitch（OVS）是一款开源的“虚拟交换机”，控制协议方面它不但支持OpenFlow的所有特性而且扩展了部分OpenFlow的功能；Overlay协议方面它支持GRE, VXLAN, STT, Geneve四种主流Overlay数据包。OVS已经是 数据平面 的事实标准了，很多白盒交换机都兼容它提供的接口；还有一些x86架构的交换机则直接是基于OVS和DPDK的。所以无论“上层”的ODL、ONOS、Neutron如何的翻天覆地的“闹腾”而OVS还是岿然不动（最后流表的执行者还是OVS）。 但是长期一来OVS都缺乏一个统一的网络模型（Neutron虽然花费巨大力气实现一个网络模型但是仅仅适用于OpenStack而无法用于容器更加无法单独使用），于是在2015年OVS社区宣布了一个子项目——Open Virtual Network（OVN）。它旨在为OVS提供一个控制平面，通过一个统一的网络模型为容器、虚拟机提供相同的网络服务。 虽然很多人不愿意承认但是事实上它瞄准的对象是三个——ODL、ONOS、Neutron。我们可以看一下OpenStack中networking-ovn子项目，它是基于OVN实现的“Neutron”旨在替换Neutron的L2、L3功能。对比传统的Neutron的L2、L3的实现代码它的代码量非常少

两个星期前， 我在博客里讨论了ASP.NET的一个新MVC（模型、视图，控制器）框架 ，我们将在不久的将来作为一个可选功能来支持。该框架提供了一个结构化的模型，来加强应用中的清晰关注分离，方便你单元测试代码和支持TDD流程。它还提供了对你在应用中发布的URL的更多的控制，也可以对从中输出的HTML提供更多的控制。 之后，我回答了来自迫切想了解更多详情的很多人的很多问题。鉴于如此高的兴趣，我觉得，写几个贴子更详细地描述如何使用这个框架，也许更有意义些。这是我将在以后几个星期里要撰写的相关贴子的第一个。 一个简单的电子商务店面应用 我将使用一个简单的电子商务商店应用来示范ASP.NET MVC框架的工作原理。在今天的贴子里，我将实现一个产品列单，以及相关的浏览应用场景。 具体来说，我们将建造一个网上商店，允许用户在访问该网站上的 /Products/Categories 网址时 浏览产品分类列表： 当用户点击上面网页上的产品分类链接时，他们将转到一个产品分类列表URL /Products/List/CategoryName 上，该页面列出了指定分类中的还在销售的产品： 当用户点击个别的产品时，他们将转到产品细节URL /Products/Detail/ProductID 上，这个网页将显示用户选定的产品的更多细节： 我们将使用新的ASP.NET MVC框架来实现上述的所有功能

基本思路 1. 为什么要做组件化？ 无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。 减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux + Mono来部署.net应用，避开Windows Server的费用。 提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是 每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部 分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。 我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门， 座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎 拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。