component定义（Angular4 - component和directive的区别）

本文目录

• Angular4 - component和directive的区别
• 投影仪上的component是什么意思
• intent的component属性的作用是什么，如何定义此属性
• NET类，组件，控件以及组件和控件的区别
• Vue单文件组件的如何使用方式介绍

Angular4 - component和directive的区别

在AngularJS 1.x版本很重要的一个部分 - 指令，用过AngularJS的同学都不陌生（这是废话）。也写过很多自定义指令。如果你学习了Angular2或者以上版本（后文我们就特指Angular4），可能会觉得Component就是之前的指令，那么问题来了，Angular4中的component和directive有什么区别？本文将详细的对比二者区别；

AngularJS1.x版本中的指令具有2个用法

（1）在已经存在的dom元素上添加一些行为

（2）创建一个组件，附上一些行为

在Angular4（在Angular2中就有，再次说明下，后面为了不再繁琐的说Angular2或者Angular4，统一称为Angular4） 中将二者明确的划分出来，component的用途是创建一个组件并附上一些行为，而directive则是在已经存在的dom元素上附加一些行为；二期详细区别如下：

（1）component使用的注解@Component修饰，directive使用注解@Directive来修饰

（2）component是通过组件化思想，基于组件来创建应用，把应用划分成细小的各个可重复使用的组件，遵循DRY原则（Don’t repeat youself！），directive是用来在已经存在的dom元素上实现一些行为

（3）component是可重复使用的组件，directive是可重复使用的行为

（4）component有创建一个视图view，即有template或者templateUrl，directive则没有。

下图是一个指令，用以实现元素的“有无”，通过指令*showAuthed=“true/false”来实现不同权限状态下改dom元素的有无；可重复使用，这指令可以放在应用中的任何一个已存在的dom元素上，来根据权限状态来控制元素的有无，非常方便

投影仪上的component是什么意思

复合视频接口：复合视频（Composite Video）信号定义为包括亮度和色度的单路模拟信号，也即从全电视信号中分离出伴音后的视频信号，这时的色度信号还是间插在亮度信号的高端。由于复合视频的亮度和色度是间插在一起的，在信号重放时很难恢复完全一致的色彩。这种信号一般可通过电缆输入或输出到家用录像机上，其信号带宽较窄，一般只有水平240线左右的分解率。早期的电视机都只有天线输入端口，较新型的电视机才备有复合视频输入和输出端（Video In，Video Out），也即可以直接输入和输出解调后的视频信号。视频信号已不包含高频分量，处理起来相对简单一些，因此计算机的视频卡一般都采用视频输入端获取视频信号。由于视频信号中已不包含伴音，故一般与视频输入、输出端口配套的还有音频输入、输出端口（Audio In、Audio Out），以便同步传输伴音。因此，有时复合式视频接口也称为AV（Audio Video）口。

intent的component属性的作用是什么，如何定义此属性

在应用中，我们可以以两种形式来使用Intent：
直接Intent：指定了component属性的Intent(调用setComponent(ComponentName)或者setClass(Context, Class)来指定)。通过指定具体的组件类，通知应用启动对应的组件。
间接Intent：没有指定component属性的Intent。这些Intent需要包含足够的信息，这样系统才能根据这些信息，在在所有的可用组件中，确定满足此Intent的组件。
对于直接Intent，Android不需要去做解析，因为目标组件已经很明确，Android需要解析的是那些间接Intent，通过解析，将 Intent映射给可以处理此Intent的Activity、IntentReceiver或Service。
Intent解析机制主要是通过查找已注册在AndroidManifest.xml中的所有IntentFilter及其中定义的Intent，最终找到匹配的Intent。在这个解析过程中，Android是通过Intent的action、type、category这三个属性来进行判断的，判断方法如下：
如果Intent指明定了action，则目标组件的IntentFilter的action列表中就必须包含有这个action，否则不能匹配;如果Intent没有提供type，系统将从data中得到数据类型。和action一样，目标组件的数据类型列表中必须包含Intent的数据类型，否则不能匹配。
***隐藏网址***
如果Intent指定了一个或多个category，这些类别必须全部出现在组建的类别列表中。比如Intent中包含了两个类别：LAUNCHER_CATEGORY 和 ALTERNATIVE_CATEGORY，解析得到的目标组件必须至少包含这两个类别。

NET类，组件，控件以及组件和控件的区别

组件和控件的区别：
1、Component在Run Time时不能呈现UI，而Control可以在Run Time时呈现UI（但是vs 2005里的asp.net中的SqlDataSource是Control，但是它不能呈现UI）。
2、Component是贴在容器Container上的，而Control则是贴在Windows Form或者Web Form上的。
举例来说，SqlCommand是个Component，DataGrid则是一个Control。
类：
如果您的类使用外部资源但不用于设计图面，则实现 System.IDisposable，或者从直接或间接实现 IDisposable 的类派生。
如果您的类要用于设计图面（如 Windows 窗体或 Web 窗体设计器），则实现 System.ComponentModel.IComponent，或者从直接或间接实现 IComponent 的类派生。请注意，IComponent 扩展 IDisposable，因此 IComponent 类型始终是IDisposable 类型。与不是 IComponent 的 IDisposable 类型相比，IComponent 类型的性能系统开销要小。但这一不足通常可由在设计时和运行时安置 IComponent的能力来弥补。（在本主题的后面部分将对该安置功能进行说明）。
如果希望类可设计（在设计图面上使用）并且可按引用封送，可从 System.ComponentModel.Component 派生。Component 是按引用封送的 IComponent 类型的基实现。
如果希望可设计的类可按值封送，可从 System.ComponentModel.MarshalByValueComponent 派生。MarshalByValueComponent 是按值封送的 IComponent 类型的基实现。
如果希望向对象模型层次中引入 IComponent 类型，但由于单次继承的原因而不能从 Component 或 MarshalByValueComponent 之类的基派生，请实现IComponent。
如果需要提供用户界面的可设计类，则该类是控件。控件必须直接或间接从下列基控件类之一派生：System.Windows.Forms.Control 或 System.Web.UI.Control。
注意
如果您的类既不是可设计类，也不保存外部资源，则不需要 IComponent 或 IDisposable 类型。
下面是组件、控件、容器和站点的定义。
组件
在 .NET Framework 中，组件是指实现 System.ComponentModel.IComponent 接口的一个类，或从实现 IComponent 的类中直接或间接派生的类。在编程中，“组件”这个术语通常用于可重复使用并且可以和其他对象进行交互的对象。.NET Framework 组件满足这些一般要求，另外还提供诸如控制外部资源和设计时支持等功能。
控制外部资源
IComponent 接口扩展 IDisposable 接口，后者在其协定中有一个名为 Dispose 的方法。在其 Dispose 方法实现中，组件必须显式释放外部资源。与垃圾回收过程中发生的默认、不确定的清理相比，这提供了一个确定的方法来释放资源。开发人员必须在整个包容层次结构中传播 Dispose以确保组件的子级同时释放资源。另外，派生的组件必须调用其基类的Dispose 方法。
注意
即使通过 Dispose 提供对资源的显式控制，也应该始终通过终结器（析构函数）提供隐式清理，以防用户未能对您的组件调用 Dispose 时资源永久泄漏。
下面的示例显示了在基组件和在派生的组件中实现 Dispose 的方式。
C#
public class BaseComponent : IComponent {
// IComponent extends IDisposable.
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing) {
if (disposing) {
// Free other state (managed objects).
}
// Free your own state (unmanaged objects).
}
// Simply call Dispose(false).
~BaseComponent(){
Dispose (false);
}
}

// Derived component.
public class DerivedComponent : BaseComponent {
protected override void Dispose(bool disposing) {
if (disposing) {
// Free other state.
}
// You must invoke the Dispose method of the base class.
base.Dispose(disposing);
// Free your own state.
...
}
// No finalizer/destructor.
// No Dispose() method.
}
设计时支持
在 .NET Framework 中，组件的一个重要功能就是它们是可设计的，这意味着作为组件的类可用于快速应用程序开发 (RAD) 环境（如 Visual Studio）中。可将组件添加到 Visual Studio 的工具箱中，也可将组件拖放到某个窗体上，还可以在设计图面上对组件进行操作。请注意，对 IComponent 类型的基本设计时支持已经内置于 .NET Framework 中；组件开发人员无须进行额外的工作就可利用基本设计时功能。
有关设计时支持的更多信息，请参见组件的设计时属性 (Attribute) 和扩展设计时支持。
承载组件
组件可以被放置（承载）在一个容器（本主题稍后部分进行了定义）中。当组件被放置后，它通过其站点（本主题稍后部分进行了定义）与容器进行交互并能够通过站点从其容器查询并得到服务。为了确保容器拆卸后资源被释放，容器必须实现 IDisposable 接口。在其 Dispose 方法的实现中，容器必须释放它保留的所有资源，并调用它包含的每个组件的 Dispose 方法。
包容是逻辑上的，不需要可视的表示形式。放置数据库组件的中间层容器就是非可视包容的一个示例。可在 Visual Studio 的 Windows 窗体设计器和 Web 窗体设计器中找到可视包容。可视化设计图面是承载窗体组件（Web 窗体中的页组件）的容器。
封送组件
组件可以是可远程控制的或不可远程控制的。可远程控制的组件由引用或值进行封送。封送涉及跨边界（如应用程序域（轻量进程）、进程、甚至是计算机）发送对象。当对象由引用封送时，会创建一个代理对该对象进行远程调用。当对象由值进行封送时，跨相关边界发送该对象的一个序列化的副本。
以下可远程控制的组件应该由引用封送：封装系统资源的可远程控制组件，较大的可远程控制组件或作为单个实例存在的可远程控制组件。由引用封送的组件的基类是System.ComponentModel.Component。该基类实现 IComponent 并从 MarshalByRefObject 派生。.NET Framework 类库中的许多组件从 Component 派生，包括System.Windows.Forms.Control（Windows 窗体控件的基类）、System.Web.Services.WebService（使用 ASP.NET 创建的 XML Web 服务的基类）和System.Timers.Timer（生成递归事件的类）。
仅保留状态的可远程控制组件应该由值封送。由值封送的组件的基类是 System.ComponentModel.MarshalByValueComponent。该基类实现 IComponent 并从 Object 派生。.NET Framework 类库中只有少量组件从 MarshalByValueComponent 派生。所有此类组件都在 System.Data 命名空间中（DataColumn、DataSet、DataTable、DataView 和 DataViewManager）。
注意
按值和按引用封送的对象的基类分别是 Object 和 MarshalByRefObject，但对应的派生类名为 MarshalByValueComponent 和 Component。命名方案背后的逻辑是越常用的类型，其名称就越简单。
如果不对组件进行远程控制，则不要从 Component 的基实现派生，而应直接实现 IComponent。
有关对象远程控制的更多信息，请参见 .NET 远程处理概述。
控件
控件是提供（或实现）用户界面 (UI) 功能的组件。.NET Framework 为控件提供两个基类：一个用于客户端 Windows 窗体控件，另一个用于 ASP.NET 服务器控件。它们是System.Windows.Forms.Control 和 System.Web.UI.Control。.NET Framework 类库中的所有控件直接或间接从这两个类派生。System.Windows.Forms.Control 从Component 派生，本身提供 UI 功能。System.Web.UI.Control 实现 IComponent 并提供可在其上轻松添加 UI 功能的基础结构。
注意
每个控件都是一个组件，但并不是每个组件都是控件。
在.net环境下编写Windows Form 控件非常的简单，只要直接和间接继承与System.Windows.Forms.Control即可，Control类为我们提供了很多高级的特性，如：窗口句柄、管理消息、鼠标和键盘事件、可视化属性（Color、Size、Position）、安全和线程支持等等，有了这些高级的特性，我们编写Windows Form 控件就简单的多，同时我们也可以把更多的精力放在我们应该关注的地方，如UI如何画、数据的Binding和显示
在.net下编写Windows Form 控件有三种方式，从System.Windows.Forms.Control派生的自定义控件、从已有的控件派生（如System.Windows.Forms.TextBox）的扩展控件、从System.Windows.Forms.UserControl派生的组合控件，很多的朋友都分不清楚UserControl和Control之间的区别，不知道到底从哪个类进行派生，简单的说：UserControl比Control更高级，提供了更多的高级特性，Control 类只提供控件所需的所有基本功能（包括鼠标和键盘处理事件），但不提供可视化的UI，所以说从Control派生的话，用户必须override OnPaint，UserControl相比Control为我们提供了更多的特性，但是UserControl也就失去了更多的灵活性
组件和控件的设计时考虑：
Designer顾名思义就是为Component设计时服务的，Designer可以在设计时修改组件的行为，还可以提供它自己的服务和行为。
在.net里要为Control或者Component定制Designer，只要从IDesigner继承下来即可，但是在.net里ms已经帮我们做了两个从IDesigner继承下来的基类，ComponentDesigner和ControlDesigner，ComponentDesigner是为Component而设计的，ControlDesigner是为Control而设计的，所以我们可以直接从ComponentDesigner继承。
Designer可以提供右键快捷菜单上的菜单命令，我们可以通过实现ComponentDesigner 谓词（Verbs） 属性来定义 get 访问器，该访问器返回的 DesignerVerbCollection 中包含用于生成菜单命令的 DesignerVerb 对象。同时我们对组件被双击时定制默认操作，在Component Designer实现 DoDefaultAction 方法即可
组件的文档设计器
每个Component不但是有Component Designer，而且还有Component DocumentDesigner，但这两个Designer之间到底有什么样的区别呢？我用比较通俗的讲法来给大家区别下，Component Designer是指一个Component被拖放到Form或者Page的Container上时所呈现出来的UI设计器（图1）；Component DocumentDesigner则是指Component本身根文档设计器（图2）
12
容器和站点
如果您正在为 Windows 窗体或 Web 窗体页（ASP.NET 页）开发组件和控件，则不需要实现容器或站点。Windows 窗体和 Web 窗体的设计器就是 Windows 窗体和 ASP.NET 服务器控件的容器。容器向放置在其中的组件和控件提供服务。在设计时，控件放置在设计器中并从设计器获得服务。为了保持完整性，以下给出了容器和站点的定义。
Container
容器是一个实现 System.ComponentModel.IContainer 接口的类，或从实现该接口的类派生的类。容器在逻辑上包含一个或多个组件，这些组件叫做容器的子组件。
Site
站点是一个实现 System.ComponentModel.ISite 接口的类，或从实现该接口的类派生的类。站点由容器提供，用来管理其子组件及与子组件进行通信。通常，容器和站点作为一个单元来实现。

Vue单文件组件的如何使用方式介绍

在很多 vue项目中，我们使用 vue.component 来定义全局组件，紧接着用 new vue(el: ”)在每个页面内指定一个容器元素
这种方式在很多中小规模的项目中运作的很好，在这些项目里 JavaScript 只被用来加强特定的视图。
但挡在更复杂的项目中，或者你的前端完全由 javascript 驱动的时候，下面这些缺点将变得非常明显：
全局定义 （global definitions）强制要求每个 component 中的命名不能重复
字符串模板 (string templates)缺乏语法高亮，在 html 有多行的时候，需要用到丑陋的 \
不支持 CSS （no css support）意味着当 html 和 javascript 组件化时，css 明显被遗漏
没有构建步骤 ( no build step)限制只能使用 html和 es5 javascript ，而不能使用预处理器，如 pug(formerly jade)和 babel

文件扩展名为 .vue 的 sigle-file components(单文件组件）为以上所有问题提供了解决方法，并且还可以使用 webpack 或 browserify 等构建工具
这是一个文件名为 hello.vue的简单实例
《template》
《p》 {{ gretting}} world! 《/p》
《/template》
《script》
module.exports = {
data: function(){
return {
greeting: ’hello’
}
}
}
《/script》
《style scoped》
p {
font-size: 2em;
text-algin: center
}
《/style》
现在我们获得：
完整语法高亮
commonJs 模板
组件化的 css
正如我们说过的，我们可以使用预处理器来构建简洁和功能更丰富的组件，比如 pug,babel,和 stylus
《template lang="jade"》
div
p {{greeting}} world!
other-component
《/template》
《script》
import default{
data(){
return{
greeting:’hello’
}
},
components: {
OtherComponent
}
}
《/script》
《style lang=’stylus’ scoped》
p
font-size: 2em;
text-align: center
《/style》
这些特定的语言只是例子，你可以只是简单地使用 Babel，TypeScript，SCSS，PostCSS - 或者其他任何能够帮助你提高生产力的预处理器。如果搭配 vue-loader 使用 Webpack，它也是把 CSS Modules 当作第一公民来对待的。
怎么看待关注点分离？
一个重要的事情值得注意，关注点分离不等于文件类型分离。
在现代 UI 开发中，我们已经发现相比于把代码库分离成三个大的层次并将其相互交织起来，把它们划分为松散耦合的组件再将其组合起来更合理一些。
在一个组件里，其模板、逻辑和样式是内部耦合的，并且把他们搭配在一起实际上使得组件更加内聚且更可维护。
即便你不喜欢单文件组件，你仍然可以把 JavaScript、CSS 分离成独立的文件然后做到热重载和预编译。
《!-- my-component.vue --》
《template》
《div》This will be pre-compiled《/div》
《/template》
《script src="./my-component.js"》《/script》
《style src="./my-component.css"》《/style》