精华内容
下载资源
问答
  • 但同样是这些大词,经过太多人的传递、消费之 后,原本的含义反而像硬币上的图案一样被磨损殆尽:几乎没有人知道这些说法到底是指什么了。在IT业界,“平台(platform)”、“框架 (framework)”、“构架...

    1
    人们总是偏爱“大词”。一个表达方式,如果听起来足够响亮,写在纸上能够吸引眼球,那就会变成很多人的新宠。但同样是这些大词,经过太多人的传递、消费之 后,原本的含义反而像硬币上的图案一样被磨损殆尽:几乎没有人知道这些说法到底是指什么了。在IT业界,“平台(platform)”、“框架 (framework)”、“构架(architecture)”等等就是这种人见人爱的大词。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。 久而久之,这些说法似乎适用于各个领域、各个层面:所有的软件系统都是“平台”,所有的开发者都在自矜于独有的“框架”。原本有确切意义的“好词”,经过 这一番争夺和滥用,也只能衰减为所谓的“buzzwords”,供市场营销人士们玩味了。
    我想让这些词中的一个——“框架”——荡污涤垢,重现青春。要完成这样的任务,必须动用重典才行。软件业圣经《设计模式》对框架有如下定义:“A framework is a set of cooperating classes that make up a reusable design for a specific class of software(一个框架,就是一组相互协作的类,对于特定的一类软件,框架构成了一种可重用的设计)”。这个定义虽然主要着眼于面向对象的软件开发,但已经基本上给出了这个词的核心含义:框架是软件系统的设计、开发过程中的一个概念,它强调对以完成的设计、代码的重复使用,并且,一个框架主要适用于实现某一特定类型的软件系统。
    为了更好地说明框架是什么,也许还应该看看框架不是什么。
    框架不是现成可用的应用系统。它仍是一个半成品,等待后来者做“二次开发”,实现为具体的应用系统。
    框架不是“平台”。后者的概念更加浮泛和模糊——人们说的一个平台,可以是一种操作系统,一种应用服务器,一种数据库软件,一种通信中间件等等,因此“平 台”几乎成了所有系统软件的统称。在平台的大家族中,框架的概念可能与近来人们常说的“应用平台”最为接近,但平台主要指提供特定服务的系统软件,而框架 则更侧重于设计、开发过程,或者可以说,框架通过调用平台提供的服务而起作用。
    框架不是工具包(toolkit)/类库(library)/API。目前流行的很多框架中,就包括了大量的类库和API,但是调用API并不就是在使用 框架开发。仅仅使用API时,开发者完成系统的主体部分,并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分,“二次开发者” 只是像做填空题一样,根据具体业务,完成特定应用系统中与众不同特殊的部分。
    框架不是构架(architecture)。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比构架更具体,更偏重于技术实现。确定框架后,构架也随之确定,而对于同一种构架(比如web开发中的MVC),可以通过多种框架(比如Apache Struts或Apache Velocity)实现。

    2

    那么,在企业应用系统开发中,框架具有什么样的意义?要阐明这一点,大概要看一看在这个领域里软件开发方式的演变。在计算机应用普及之前,只有少数大企业才负担得起企业信息系统软件,这一类的软件开发也已委托定制(custom-made software)为主。在企业信息化基础设施逐步完备之后,多数中、小企业也要在预算不高的前提下实施企业应用系统,按照以前的方式逐个定制开发,是这种类型的企业难以承受的。因此,对于一些需求简明的系统,往往会购买现成软件(shrink-wrapped software)解决问题。但是各个企业具体业务不同,需求很难统一,现成软件只能满足最通用的情况和最一致的操作(比如财会系统、网站内容发布系统等),对于头绪众多的业务处理就难以胜任了。
    如何最大程度地萃取不同企业应用系统的共性,重复使用已经完成的设计和代码,对企业应用系统中典型场景给出最佳解决方案——这是一个“一般性”的问题;如 何让一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求——这是一个“特殊性”的问题。作为对这一组冲突的一种解决方案,不少厂商推出了自己的企 业应用框架。这些框架往往是从大量的委托项目开发中精选出的系统“不变项”,因此具有很强的普适性和实用性。
    目前,主流企业应用框架中大都包含对以下问题的现成解决方案:
    * 持久性(persistence):实现数据存储、处理,数据与对象映射,数据缓存(caching)。
    * 事务(transaction):确保一组关联操作正常、完整的执行。
    * 安全性(security):保证系统的通信安全、数据安全。
    * 负载均衡(load balance):在大量并发访问时,保持系统可用。
    * 监控(system monitoring/management):监控系统运行状况,设置系统参数。
    * 日志(logging):记录系统运行情况和异常,记录特定用户操作。
    * 应用集成 (application integration):与其他系统、应用程序集成。
    * 认证/权限/组织角色管理(authentication/authorization):管理系统用户、组织职权结构,限制特定用户对特定功能、特定数据的访问。
    * 业务模型(domain model):管理系统中业务对象的属性、字段。
    * 业务逻辑(business logic/rules):实现业务规则和业务逻辑。
    * 工作流(work flow):实现多用户、多环节之间的业务处理流程。
    * 文件管理(file management):管理文档,实现系统内部的文件传递。
    * 报表/打印 (reporting/printing):实现数据打印,实现报表的定制和输出。
    * 门户/信息发布 (portal solution):发布企业相关的信息、新闻,提供企业客户的访问入口。
    * 通信(communication/messaging):系统内部的消息、通知;系统与外部角色(比如企业客户)之间通过不同通信媒介(电话、网站、邮件等)的互动。
    * 特定行业/领域模块 (business modules):实现特定行业、流域相关的业务模块。
    以上诸方面中,除了前四项目前主要由应用服务器解决之外,其他的部分本身都是专门的软件开发领域。框架的作用,在于确定上述每种因素的具体技术实现,并规定它们在系统中的组织方式和协作方式,从而给出完整的企业应用解决方案。
    企业应用框架的特点首先是,当应用框架确定之后,系统的整个构架,也就是主体结构就已经固定。因此框架的选取往往是方案选型的首要问题。
    其次,人们常常听信“组件式开发”的一面之词,认为系统搭建的过程类似于搭积木,好像是用胶水代码(glue code)拼合现成的组件或模块。其实采用框架开发时,系统的构建过程更类似于填空——系统骨架早已完成,开发者填写特定的代码,由系统来调用。《设计模式》中提到的“好莱坞原则(the Hollywood principle——Don't call us, we'll call you)”,非常符合我们谈的这种情况。很多框架还允许下游厂商开发系统插件(plug-ins),以满足特定需要——这是另一种形式的“填空”。
    另外,对于实现具体应用系统的二次开发者来说,不少任务都无需通过编程实现。比如要给一个业务模型增添一个新字段,或是要设置一种新的工作流程,这些工作 都可以通过简单的图形用户界面(GUI)操作,或是修改部署描述符(DD),或是编写脚本来完成。也就是说,相当多(而不是全部)的开发任务是通过声明/ 配置的(declarative),而不是编程的(programmatic)的方式实现的。系统往往会在启动或运行时载入相关的配置,据此实现特定的功 能。

    企业应用框架是菜场里的半成品。当我们面对要么自己下厨、要么去饭馆吃饭的选择时,我们往往会采取这种省时省力的折衷方案。但是选择之所以为选择,就因为其中肯定包含对收益和代价的权衡,都隐含着复杂的利弊关系(pros and cons)。下面我们也来检讨一下企业应用框架的情况:
    Pros:
    * 缩短开发周期
    毫无疑问,采用框架的开发,要比一切从头做起快速、高效得多。通过一般化(generalization)和重用(reuse)机制,框架能最大限度地加快一个特定应用系统的实现。
    * 客户化
    如上所述,基于框架的系统有很多功能通过配置而不是编程实现,这样也给用户带来了一定便利。比如,企业内部的IT人员经过一定培训,就能够自己完成一种新的工作流程的设置。这对于不断变化的业务需求是一个很理想的解决方案。
    * 不重新发明轮子
    框架对于大量典型场景给出了最优的实践。在具体开发时,与其无视前人的成果,重新构思答案,不如套用这些成熟、稳定的做法。这不仅能加快开发进度,更能够提升系统的质量和健壮性。
    * 可维护性/知识共享
    完全通过委托开发完成的系统很难由其他厂商维护。框架往往是多个企业、大量开发者实践的成果,因此能在一定程度上打破上述壁垒,增进系统的可维护性。当框架使用者形成社区之后,还能实现更高层次上的知识共享。
    Cons:
    * 太多
    半成品总有其代价。超市配好的一包菜里,老是又我们用不到的调料——但是我们却不得不为之付费。同样,为了达到一般性和普适性,框架总比紧凑、贴切的特定 应用多出不少内容。二次开发完成后,企业获得的只是一种特定的实现,却要为所有的客户化可能性付费,为所有用不上的功能付费。这是一个相当让人尴尬的事 实。
    * 太少
    框架总是一种限制。就像半成品菜限制了我们的烹调方法,框架也限制了我们实际应用的可能性。当框架本身设计的足够普适时,我们不太会感到类似的限制。但 是,情况往往正好相反——面对一个足够特殊的需求,二次开发者总有一种冲破框架的渴望。最后的解决办法,往往是狡计、妥协和框架补丁的结合体。
    * 效率
    上面说过,基于框架的系统中,具体功能经常是通过配置实现的。与硬编码(hard-coded)的方式相比较,这虽然能提供很大的灵活性,但也往往牺牲了运行时的效率。
    * 锁定
    一个采用特定框架的系统几乎肯定被锁定在这个厂商的产品上。换言之,框架意味着all or nothing式的态度,很难调和两种不同的框架,各取所长,更难把应用系统从一个框架迁移到另一个——这往往要求系统的全部改写。
    * 学习曲线
    一种框架也就是一种方言。要精通特定框架的开发,你要熟悉其中的所有的用法、思路和弱点。对于开发者,这也意味着比较陡峭的学习曲线。

    3

    上面谈到的种种弊端,还属于一般开发框架共有的缺陷。对于市面上流行的很多企业应用框架来说,更大的问题是框架产品自身的价格过高。我在别处也讲过,企业 应用系统项目往往不能靠运行安装程序,再作简单的设置就完成,而是一个复杂、漫长、不断尝试/修改的过程,或者说,更近似于一种服务而不是简单的产品销 售。但是框架厂商的产品(或者说是半成品)价格过高,经常就蚕食了整个系统的大部分开发预算,使方案总价偏重于框架本身而不是后期开发。对于需求不甚符合 原有框架,需要大量开发的项目,或是需求本身不够清晰的项目,这都几乎肯定会导致整个项目的失败。

    软件工程宗师F. Brooks曾经表述过这样一个道理:没有银弹(No Silver Bullet/NSB)。那意思是说,没有一种万应药能够戏剧性地提升软件开发的效率和质量。最近的很多舆论好像是专门和这个经典论述抬杠,动不动就把一 些特殊的解决方案奉为银弹。对于企业应用开发而言,基于框架的开发模式是多种选择中的一种。在不少情况下,这种选择是不错的,但同时应该留意随之而来的风 险,更不该以为,选定了框架就一定能保证项目成功。
    很多企业应用项目的难点,在于客户自身缺乏规范的企业管理制度和合格的计算机应用水平。客户不具备成型的业务流程,也无法明晰表达需求,不知道怎样的应用 形式对自身业务更合理:这种需求不清、或是需求剧烈变更的困境是困扰大量企业应用开发项目的症结。简言之,企业应用项目的成败经常是“业务”、“技术”、 “管理”三种因素共同作用的结果,而单纯引入框架,只能解决部分“技术问题”。如果过于乐观地估计框架在其中的作用,甚至认为它能解决任何项目的任何问 题,这对于本领域的各个环节(厂商、项目开发商、企业客户)都只能起到消极作用。
    我个人的建议是:在搭建企业应用系统时,针对应用情况不同、预算/时限不同、对系统指标要求不同,有多种替代方案可以从中选择。当需求明确、固定,又有现 成产品完全满足需要时,或者当企业想要以极低预算消除某个业务瓶颈时,应该优先考虑现成产品;在需求明确、固定,但很难被现成产品完全覆盖时,可以选择应 用框架,并由合格开发商完成实施;在需求不够明确,或者预感到需求会发生剧烈变更时,采用开发源码的应用框架,从而避免高昂的初期投资,并“软化”框架带 来的种种限制,是另一种可供选择的思路。还是那个比方,一顿饭怎么吃,究竟是下馆子、买半成品或者全由自己动手,还要视具体情形而定——我也希望,每个企 业都能吃上可口顺心的应用大餐。

    展开全文
  • 精炼版本 架构是顶层设计; 框架是面向编程或配置的半成品; 组件是从技术维度上复用; 模块是从业务维度上职责划分; 系统是相互协同可运行实体。

    💨 作者:laker,因为喜欢LOL滴神faker,又是NBA湖人队🏀(laker)粉丝儿(主要是老詹的粉丝儿),本人又姓,故取笔名:laker
    ❤️喜欢分享自己工作中遇到的问题和解决方案以及一些读书笔记和心得分享
    🌰本人创建了微信公众号【Java大厂面试官】,用于和大家交流分享
    🏰 个人微信【lakernote】,加作者备注下暗号:cv之道


    精炼版本

    • 架构是顶层设计;
    • 框架是面向编程或配置的半成品;
    • 组件是从技术维度上的复用;
    • 模块是从业务维度上职责的划分;
    • 系统是相互协同可运行的实体。

    骚话版本

    搬砖的:“头,我们要造什么?”;(做什么系统?)
    工程师:“龙之梦商城”;(XXX系统,比如微博系统)
    搬砖的:“图纸画出来了嘛?”;(架构是怎么设计的?)
    工程师:“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”;(相当于微博系统中的各个子系统,比如评论子系统、动态子系统、消息子系统)
    搬砖的:“头,说人话”;
    工程师:“一楼有卖衣服、化妆品的,二楼有唱歌、看电影的,三楼有吃的”;(【模块】按照逻辑区分,比如存储数据模块、搜索模块、消息推送模块)
    搬砖的:“有没有很知名的店啊?”;
    工程师:“有的,一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”;(【组件】按照物理区分,存储数据模块对应Mysql、搜索模块对应ElasticSearch、 消息推送模块对应Kafka)
    搬砖的:“对了,头,商城大门有啥需要叮嘱的施工规范不?或有啥简化施工工艺的新技术嘛?”;(有框架的可以用吗?)
    工程师猛吸了一口烟,把烟头扔在地上,用皮鞋左右撵了两下,缓缓从嘴里崩出四个字。 “老样子吧”。(Spring全家桶甩起来)
    

    在《从零开始学架构》学了一手,记录一下

    为何结构化编程、面向对象编程、软件工程、架构设计最后都没有成为软件领域的银弹?

    在古代的狼人传说中,只有用银质子弹(银弹)才能制服这些异常凶残的怪兽。在软件开发活动中,“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。

    软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看,先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是,这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点:我们可以通过诸多方式去接近“银弹”,但很遗憾,软件活动中没有“银弹”。

    布鲁克斯发表《人月神话》三十年后,又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计,架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得,对这个平衡点的把握,就是架构设计中的取舍问题。而这种决策大部分是靠技术,但是一定程度上也依赖于架构师的“艺术”,技术可以依靠新工具、方法论、管理模式去提升,但是“艺术”无法量化 ,是一种权衡。

    软件设计过程中,模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论,软件架构是一种对软件的“组织”方法论。一分一合,其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是,一个成功的软件设计是要适应并满足业务需求,同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”,这就决定了这是一个动态活动,出现新问题,解决新问题,没有所谓的“一招鲜”。

    以上只是针对设计领域的银弹讨论,放眼到软件全生命周期,银弹问题会更加突出。

    小到一个软件开发团队,大到一个行业,没有银弹,但是“行业最佳实践”可以作为指路明灯,这个可以有。

    展开全文
  • WIP全称:Work in progress,正在工作过程中,引申含义为“目前工作区中代码正在编写中,这部分代码不能独立运行,是半成品”。 WIP其实代表就是WIP版本里面代码是“正在工作并编写代码”,意思便是"代码...

    1.问题背景

    在使用git stash命令时,我们会注意到有很多的WIP单词,但我们很想知道WIP含义。
    在这里插入图片描述
    在这里插入图片描述
    WIP全称:Work in progress,正在工作过程中,引申含义为“目前工作区中的代码正在编写中,这部分代码不能独立运行,是半成品”。
    WIP其实代表的就是WIP版本里面的代码是“正在工作并编写的代码”,意思便是"代码工作只开发了一半,不能独立的运行"。直接把这种半成品代码提交commit是极其不合适的,但是我们可以把这部分代码git stash储藏起来,并用WIP给他们做标记。

    本文参考来源:
    [1]GitHub: What is a “wip” branch?

    展开全文
  • 用于listen监听句柄也是使用close关闭,关闭这样句柄含义当然很不同,它本身并不对应着某个TCP连接,但是,附着在它之上却可能有半成品连接。什么意思呢?之前说过TCP是双工,它打开需要三次握手,三次...

    socket的关闭有close 和shutdown两种API,那么他们的区别在哪里呢?

    close ----- 在多进程的情况下,关闭本进程的socket,但这只是socket的引用计数减1,用这个socket的其它进程还能用这个链接,能读或写这个socket,直到所有的进程都进行了close,才真正关闭这个套接字,但当它真正执行关闭的时候是完全关闭,既不处理发送也不处理接收数据

    shutdown – 即便在多进程的情况下面,也是直接进行关闭的,关闭了socket 文件描述符,其他进程的也会被关闭,但他关闭的时候只关闭一半,即发送数据通道关闭,接收数据还是可以的**。如果对写操作被关闭的socket执行写操作会触发写就绪(EPOLLOUT)事件,同时触发一个SIGPIPE信号。**

    close的主要流程:
    在这里插入图片描述
    1)关闭监听句柄
    先从最右边的分支说说关闭监听socket的那些事。用于listen的监听句柄也是使用close关闭,关闭这样的句柄含义当然很不同,它本身并不对应着某个TCP连接,但是,附着在它之上的却可能有半成品连接。什么意思呢?之前说过TCP是双工的,它的打开需要三次握手,三次握手也就是3个步骤,其含义为:客户端打开接收、发送的功能;服务器端认可并也打开接收、发送的功能;客户端认可。当第1、2步骤完成、第3步步骤未完成时,就会在服务器上有许多半连接,close这个操作主要是清理这些连接。
    参照上图,close首先会移除keepalive定时器。keepalive功能常用于服务器上,防止僵死、异常退出的客户端占用服务器连接资源。移除此定时器后,若ESTABLISH状态的TCP连接在tcp_keepalive_time时间(如服务器上常配置为2小时)内没有通讯,服务器就会主动关闭连接。
    接下来,关闭每一个半连接。如何关闭半连接?这时当然不能发FIN包,即正常的四次握手关闭连接,而是会发送RST复位标志去关闭请求。处理完所有半打开的连接close的任务就基本完成了。

    2)关闭普通ESTABLISH状态的连接(未设置so_linger)
    首先检查是否有接收到却未处理的消息。
    如果close调用时存在收到远端的、没有处理的消息,这时根据close这一行为的意义,是要丢弃这些消息的。但丢弃消息后,意味着连接远端误以为发出的消息已经被本机收到处理了(因为ACK包确认过了),但实际上确是收到未处理,此时也不能使用正常的四次握手关闭,而是会向远端发送一个RST非正常复位关闭连接。这个做法的依据请参考draft-ietf-tcpimpl-prob-03.txt文档3.10节,Failure to RST on close with data pending。所以,这也要求我们程序员在关闭连接时,要确保已经接收、处理了连接上的消息。

    如果此时没有未处理的消息,那么进入发送FIN来关闭连接的阶段。
    这时,先看看是否有待发送的消息。前一篇已经说过,发消息时要计算滑动窗口、拥塞窗口、angle算法等,这些因素可能导致消息会延迟发送的。如果有待发送的消息,那么要尽力保证这些消息都发出去的。所以,会在最后一个报文中加入FIN标志,同时,关闭用于减少网络中小报文的angle算法,向连接对端发送消息。如果没有待发送的消息,则构造一个报文,仅含有FIN标志位,发送出去关闭连接。

    3)使用了so_linger的连接
    首先要澄清,为何要有so_linger这个功能?因为我们可能有强可靠性的需求,也就是说,必须确保发出的消息、FIN都被对方收到。例如,有些响应发出后调用close关闭连接,接下来就会关闭进程。如果close时发出的消息其实丢失在网络中了,那么,进程突然退出时连接上发出的RST就可能被对方收到,而且,之前丢失的消息不会有重发来保障可靠性了。
    so_linger用来保证对方收到了close时发出的消息,即,至少需要对方通过发送ACK且到达本机。
    怎么保证呢?等待!close会阻塞住进程,直到确认对方收到了消息再返回。然而,网络环境又得复杂的,如果对方总是不响应怎么办?所以还需要l_linger这个超时时间,控制close阻塞进程的最长时间。注意,务必慎用so_linger,它会在不经意间降低你程序中代码的执行速度(close的阻塞)。

    所以,当这个进程设置了so_linger后,前半段依然没变化。检查是否有未读消息,若有则发RST关连接,不会触发等待。接下来检查是否有未发送的消息时与第2种情形一致,设好FIN后关闭angle算法发出。接下来,则会设置最大等待时间l_linger,然后开始将进程睡眠,直到确认对方收到后才会醒来,将控制权交还给用户进程。

    这里需要注意,so_linger不是确保连接被四次握手关闭再使close返回,而只是保证我方发出的消息都已被对方收到。例如,若对方程序写的有问题,当它收到FIN进入CLOSE_WAIT状态,却一直不调用close发出FIN,此时,对方仍然会通过ACK确认,我方收到了ACK进入FIN_WAIT2状态,但没收到对方的FIN,我方的close调用却不会再阻塞,close直接返回,控制权交还用户进程。

    从上图可知,so_linger还有个偏门的用法,若l_linger超时时间竟被设为0,则不会触发FIN包的发送,而是直接RST复位关闭连接。我个人认为,这种玩法确没多大用处。
    在这里插入图片描述
    最后做个总结。调用close时,可能导致发送RST复位关闭连接,例如有未读消息、打开so_linger但l_linger却为0、关闭监听句柄时半打开的连接。更多时会导致发FIN来四次握手关闭连接,但打开so_linger可能导致close阻塞住等待着对方的ACK表明收到了消息。

    最后来看看较为简单的shutdown。
    在这里插入图片描述
    1)shutdown可携带一个参数,取值有3个,分别意味着:只关闭读、只关闭写、同时关闭读写。
    对于监听句柄,如果参数为关闭写,显然没有任何意义。但关闭读从某方面来说是有意义的,例如不再接受新的连接。看看最右边蓝色分支,针对监听句柄,若参数为关闭写,则不做任何事;若为关闭读,则把端口上的半打开连接使用RST关闭,与close如出一辙。
    2)若shutdown的是半打开的连接,则发出RST来关闭连接。
    3)若shutdown的是正常连接,那么关闭读其实与对端是没有关系的。只要本机把接收掉的消息丢掉,其实就等价于关闭读了,并不一定非要对端关闭写的。实际上,shutdown正是这么干的。若参数中的标志位含有关闭读,只是标识下,当我们调用read等方法时这个标识就起作用了,会使进程读不到任何数据。
    4)若参数中有标志位为关闭写,那么下面做的事与close是一致的:发出FIN包,告诉对方,本机不会再发消息了。

    展开全文
  • Django框架理解

    2019-04-22 19:01:52
    框架的第一含义是一个骨架,它封装了某领域内处理流程的控制逻辑,所以我们经常说框架是一个半成品的应用。由于领域的种类是如此众多,所以框架必须具有针对性,比如,专门用于解决底层通信的框架,或专门用于医疗...
  • 架构是指软件结构的专用名词,构架只是架构的另一种叫法框架指的是一些通用的结构和组件(半成品) 结构 Structure 通用的一个词,在不同专业领域可能有不同的含义。泛指一个东西、系统、概念的内部组成元素...
  • 不同的物料在编码时应区别对待,例如对于半成品,可以直接以图号作为编码进行编号,这样,在PDM、CAPP以及实际操作中更容易实施和理解。  2 物料编码原则  不需使物料编码表达较丰富的含义,只需将主要属性通过...
  • 机械制造过程中,凡是直接改变零件形状、尺寸、相对位置和性能等,使其成为成品或半成品的过程,称为机械制造工艺过程。它通常包括零件的制造与机器的装配两部分。2、机械加工工艺的作用2.1 是指导生产的主要技术...
  • 本文节选 Odoo亚太金牌服务·开源智造 老杨 所编写《ERP真免费不花钱(第三版)——Odoo14应用指南》第二章销售和发票功能应用篇之产品基础资料设置应用...在制造业中,产品可以是购买原材料或半成品,也可以是..
  • 注解是只个标记,生效的是注解解析器,注解的含义是通过解析器来实现的; 一级缓存存的是已实例化和初始化完成的完成品对象,初始化完成指对象中的属性已赋值; 二级缓存和三级缓存存的是已实例化,但未初始化的对象...
  • 初入爬虫框架

    2019-10-10 20:54:52
    了解Python爬虫框架 什么是python爬虫框架 简单来说,python爬虫框架就是一些爬虫项目的半成品。...这里半成品”主要有两层含义: 1)、这些框架并不是爬虫项目成品,需要用户根据具体爬虫任务更改之...
  • spring框架 ioc

    2020-08-08 23:51:00
    其实就是某种企业级应用的半成品,就是一组组件,供你选用完成你自己系统。简单说就是使用别人搭好舞台,你来做表演。而且,框架一般是成熟,不断升级软件。 框架是对特定应用领域中应用系统部分设
  • Web开发框架

    2008-04-11 08:53:00
    半成品亦是产品,这个从框架本身定义就有这层含义,而且做为产业链来看话,半成品也有极其大市场空间和多样性用途. TSYSCMS如果从这个角度来说也是个框架产品.开发框架选择,尤其是Web层开发框架,数量非常...
  • 3.hibernate

    2019-10-06 08:56:03
    3.所以框架可以理解成是一个半成品的项目.只要懂得如何驾驭这些功能即可. javaEE三层开发框架及hibernate框架对应的位置如下: Hibernate框架优点:操作数据库的时候,可以以面向对象的方式来...
  • 在SAP中,将重点关注用来直接或间接为企业增值物品,如原材料、半成品、成品、水、电、蒸汽、空气、设备、仪器仪表等等。同时,也可以把用于销售、非物质形态“服务”作为物料来管理。 主要功能 MM(物料...
  • 05.... ... 00.我们将剖析在制品(Work In Process, WIP)概念。含义:进行中工作、流程中工作。...01.在制品是指你手头正在处理...也就是,所有那些需要完结,才能交付最终客户价值的半成品。   02...
  • 框架的含义就是一个半成品软件,使用框架的好处就是程序员不需要管很多繁琐的步骤,这些是框架帮你完成的 这样程序员就可以专注于业务的实现 JDBC数据库连接我们关心的只是那条sql语句,其他都交给框架处理 ...
  • Structs2-基础

    2019-07-29 19:15:21
    框架其实就是一个半成品,一般做开发是基于框架,在框架上继续做开发。 最佳实践 三要素:可读性、可维护性、和拓展性。 Web开发中最佳实践:分层开发模式 表现层:负责处理与页面交互相关操作 ...
  • 1.2、结果不言而喻吧,有一个半成品的架子,你只需要添上一些你自己额外需要加的东西就好了。这就是框架的好处。 2、框架的好处其实框架,就是别人写好了包装起来的一套工具,把你原先必须要写的,必须要做的一些...
  • Spring 框架学习

    2019-06-03 16:56:34
    一组jar包的集合,是一个半成品,只解决某一个领域的问题 2、Spring的含义 Spring是一个轻量级的DI/IOC与AOP的容器框架 **轻量级:**相对于EJB(以前一个重量级框架)来讲的,框架更加简单,功能也很强大 ...
  • 幼儿感恩节活动计划 感恩心,感谢命运,花开花落,我一样会珍惜。感恩节到了,以下是小编精心收集整理幼儿感恩节活动,下面小编就和大家分享,来欣赏一下吧。... 2、孝亲拼图半成品3份。 3、PP...
  • Spring01

    2018-06-04 18:36:01
    框架是可以重复使用一些或一整套代码,通常与具体业务无关,也可以认为是软件的半成品。使用框架好处:简化项目开发,提高开发效率。什么又是“一站式”框架呢?JavaEE开发规范规定我们程序应该要分为三层:...
  • MyBatis框架

    2020-02-07 18:56:37
    含义半成品的软件。即这个框架帮我我们写了一部分代码,我们用这个框架,就需要按这个框架的规则来把我们要完成的任务(软件)来补充完整。框架帮我们完成的那部分代码一般包括(类型装换,加载配置文件等)。 ...
  • Bootstrap—前端框架

    2021-03-01 22:46:07
    框架:一种半成品软件,开发人员可以在框架基础上进行开发。 优点: 1) 定义了许多css样是和js插件。 是开发人员可以直接使用他们到丰富页面效果。 2) 响应式布局。(同一套页面可以兼容不同分辨率设备...
  • 框架(Framework) 是一个提供了可重用公共结构的半成品。它为我们构建新应用程序提供了极大便利。一方面提供了可以拿来就用工具,更重要是,提供了可重用设计。框架这个词最早出现在建筑领域,指是在...
  • 学习目标: 1、熟悉.net开发总体结构以及各种名词的含义 2、熟悉C#基本语法 3、熟悉asp.net的web开发思路 学习总结 ...框架——半成品 .net框架——简化了C#程序员的开发量,把通用的常用操作封装 ...
  • MM模块形象化描述

    千次阅读 2010-08-29 11:12:00
    在SAP中,将重点关注用来直接或间接为企业增值物品,如原材料、半成品、成品、水、电、蒸汽、空气、设备、仪器仪表等等。同时,也可以把用于销售、非物质形态“服务”作为物料来管理。  我们将这些实物...
  • 经过将近个月时间把... 书中按照24小时来写这本书,共分24章,总体感觉这本书很少借助代码来说明问题,更多是借助了属性栏,让初学者看到了成品,但没有看到代码内在含义,这跟是不同两个方向,所以初学者

空空如也

空空如也

1 2
收藏数 30
精华内容 12
关键字:

半成品的含义