1..NET和ASP.NET分别是什么?
.NET是微软的一个开发平台,其主要核心就是.NET Framwork,这个平台的一大特点就是跨语言性,不管是什么语言,c、c++、c#、F#、J#、vb等语言都可以用这个平台合作开发;
ASP.NET是一个网站开发的技术,是.NET里面的一个模型,也是目前的一种主流开发网站的技术;
2..NET和ASP.NET区别是什么?
(1)ASP.NET是一个网站开发的技术,.NET是一个平台。
(2).NET分成两个方面:一个是WinForm,另一个是WebForm,也就是说一个基于Windows窗体,另一个基于Web窗体。
而ASP.NET是一个网站开发的技术,是WebForm,用于生成基于Web的应用程序的内容丰富的编程框架。
ASP与ASP.NET是Microsoft公司在Web应用程序开发上的两项重要技术。
ASP与ASP.NET区别如下:
(1)开发语言不同:ASP的开发语言仅局限于使用non-type脚本语言,给客户端脚本添加代码和给页面添加ASP代码的方法是一样的。
ASP.NET的开发语言更为广泛,可以使用符合.NET Framework规范的任何一种功能完善的strongly-type编程语言(比如Visual Basic、C#)。
(2)运行机制不同:ASP是解释型的编程框架,因没有事先编译,而是一边解释一边执行,故而页面的执行效率相对比较低。ASP.NET是编译型的编程框架,服务器上运行的是已经编译好的代码,因此可以利用早期绑定来实时编译,进而提高执行效率。
(3)运行环境不同:ASP的运行环境是Windows操作系统及IIS。ASP.NET的运行环境除了Windows操作系统及IIS,还需要安装.NET Framework。
(4)开发方式不同:ASP将用户界面层和应用程序逻辑层的代码混合写在一起,因此在维护和重用方面比较困难。ASP.NET将用户界面层和应用程序逻辑层的代码分离开,程序的复用性和维护性都得到了提高。
(5)诞生的时间不同:1996年11月,Microsfot公司推出了ASP(Active Server Pages)技术。2002年01月,Microsfot公司推出了ASP.NET技术。
总结:
ASP与ASP.NET虽然都是微软公司的两项Web技术,但由于它们诞生的时间与背景不同,所以它们之间的区别相对比较大,主要区别在开发语言、运行机制、运行环境、开发方式等方面的不同。
c/s
winform被称为 Windows 窗体。它是.Net 框架桌面应用程序的图形用户界面。它在 .net 框架中有一组托管库。它提供了一个广泛的客户端库,以提供从托管代码访问本机 Windows 图形界面元素和图形的界面。WPF 缩写为 Windows 演示框架。它最初是由微软在 2006 年用 .Net framework 3.0 发布的。它是一个用于构建 Windows 应用程序的图形用户界面框架。WPF 不仅仅是一个包装器;它是 .net 框架的一部分。它包含托管和非托管代码的混合。
winform
- 在Windows应用程序中,winform为Windows应用程序的开发提供了一个由一组C++类组成的包装器,winform应用程序中的每个控件都是一个类的具体实例。它提供了多种控件,例如文本框、按钮、标签和网页,以及创建自定义控件的选项。为此,Visual Studio 中有一个 winform设计器工具可用于处理窗体上的控件并根据所需的布局排列它们,以便添加代码来处理事件。
- 在 Windows 窗体中,应用程序设置是创建、存储和维护信息的另一个功能。Windows 窗体类可以使用继承进行扩展,以设计应用程序框架,提供抽象和代码可重用性。表单应该紧凑,并控制其有限的大小。表单可以分解成块,打包在可以自动更新自己的程序集中。设计应用程序为调试和维护提供了可扩展性和灵活性。Windows 窗体不能跨应用程序域边界传递。
WPF
- WPF 体系结构的主要组件是表示框架、表示核心和 mallcore。在 WPF 中,UI 元素是用 XAML 设计的,而行为可以用过程语言来实现。使用 WPF 中的 XAML,程序员可以与设计人员并行工作。WPF 是一个用于创建 Windows 应用程序的强大框架,它具有强大的功能,如数据绑定、媒体服务、模板、动画、direct3D 和替代输入。
- WPF 应用程序开发可以在 Visual Studio 和 Expression Blend 等 Microsoft 工具的帮助下完成。开发者主要使用VS来创建WPF应用程序,而设计者主要使用blend来创建WPF应用程序。
winform和 WPF 之间的主要区别
Winform 和 WPF 都是市场上流行的选择;让我们讨论一下 Winform 与 WPF 之间的一些主要区别:
- Winform不是基于矢量的 UI。而 WPF 是一个基于矢量图形的 UI 表示层。在基于矢量的帮助下,它允许表示层平滑地缩放 UI 组件,而不会出现任何尺寸失真问题。
- Winform在开发应用程序时更易于使用,而 WPF 使用起来有点困难,因为它需要良好的知识才能使用控件。
- 在Winform中,我们可以根据需要自定义控件。在 WPF 中,我们也有第三方控件来丰富应用程序的功能。
- Winform的学习曲线较少。而 WPF 需要更多的学习曲线来理解控件和设计部分的完整流程。
- Winform不那么耗时或不那么棘手。在开发应用程序时,WPF 更棘手,需要花费更多时间来完成任务。
- Winform不用于开发新应用程序。WPF 主要用于开发新的应用程序。
- Winform表单在开发人员、在线社区、库方面提供了大量支持,可在为初学者开发应用程序时提供任何帮助。WPF 也有足够的支持和库来开发应用程序并为初学者快速获得支持。
- 在 Winform中,控件很难自定义,而在 WPF 中,控件可以轻松自定义,因为它完全是从头开始编写的。
- Winform在提供一致性方面很差。WPF 在应用程序之间提供了更高的一致性。
- 在Winform中,UI 是在业务逻辑代码语言的帮助下设计的。在 WPF 中,它使用 XAML 作为标记语言来设计应用程序的 UI 部分。
- Winform主要基于像素,而 WPF 不是基于像素的,这允许应用程序的 UI 部分具有可伸缩性。
- Winform以有限的方式支持数据绑定,而 WPF 完全支持数据绑定。
- Winform不与不同的主题或皮肤一起使用。WPF 主要是可换肤或可主题化的,其中不同的皮肤或主题可用于 UI。
- Winform在设计 UI 时需要较少的精力。WPF 需要更多的努力,因为大部分工作需要自己完成。
Winform与 WPF 比较表
以下是 Winform与 WPF 之间的最高比较:
比较基础 | Winform | WPF |
进步 | Winform是开发桌面应用程序的旧概念 | WPF 是用于开发应用程序的先进或最新概念 |
简单的 | Winform易于使用,因为控件可以轻松使用。 | 与 Windows 窗体相比,WPF 使用起来很复杂。 |
可扩展 | 如果以后需要扩展 UI 元素,Winform的可扩展性就会降低。 | WPF 对于应用程序中的 UI 元素具有广泛的可扩展性 |
安全的 | Winform的安全功能较低 | WPF 具有增强的安全功能。 |
设计 | 在需要设计的地方不使用 Winform | WPF主要用于设计应用程序的UI部分 |
表现 | 在 Winform中,事情的完成速度较慢。 | 在 WPF 中,事情主要以相对非常快的速度实现。 |
前端三大框架 前端SPA三大框架的对比
通常说的三大框架,即:Angular Vue React
Angular (注:2,1的版本和2的版本简直是两种语言)是基于 TypeScript(Javascript超集)的 Javascript 框架。React 被描述为 用于构建用户界面的 JavaScript 库,Vue 为一款用于构建直观,快速和组件化交互式界面的 MVVM 框架
Angular 是一个框架而不是一个库,是一个完整的解决方案。React 和 Vue 更灵活的。Angular 必须用 TypeScript,文档均是TS的
单页面应用主要是局部刷新的优势,速度快,带宽小。客户端服务器端压力小。
一.angular
1.SPA老大哥,起源于google。
2.第一个SPA框架
3.双向绑定,MVC的解耦。
二.react
1.facebook推出
2.使用js就可以写前后端代码。
3.reactnative应用手机端很流行
三.vueJS
1.简单易学
2.其他两大框架有的功能vue都有。
3.中国人开发,文档有中英文版。
4.github上stars数增长趋势最高。
webpack和vite的比较
- 都是现代化打包工具
- 从底层原理上来说,Vite是基于esbuild预构建依赖。而esbuild是采用go语言编写,因为go语言的操作是纳秒级别,而js是以毫秒计数,所以vite比用js编写的打包器快10-100倍。
webpack: 分析依赖=> 编译打包=> 交给本地服务器进行渲染。首先分析各个模块之间的依赖,然后进行打包,在启动webpack-dev-server,请求服务器时,直接显示打包结果。webpack打包之后存在的问题:随着模块的增多,会造成打出的 bundle 体积过大,进而会造成热更新速度明显拖慢。
vite: 启动服务器=> 请求模块时按需动态编译显示。是先启动开发服务器,请求某个模块时再对该模块进行实时编译,因为现代游览器本身支持ES-Module,所以会自动向依赖的Module发出请求。所以vite就将开发环境下的模块文件作为浏览器的执行文件,而不是像webpack进行打包后交给本地服务器。
分析了webpack和vite的打包方式后,也就明白了为什么vite比webpack打包快,因为它在启动的时候不需要打包,所以不用分析模块与模块之间的依赖关系,不用进行编译。这种方式就类似于我们在使用某个UI框架的时候,可以对其进行按需加载。同样的,vite也是这种机制,当浏览器请求某个模块时,再根据需要对模块内容进行编译。按需动态编译可以缩减编译时间,当项目越复杂,模块越多的情况下,vite明显优于webpack.
热更新方面,效率更高。当改动了某个模块的时候,也只用让浏览器重新请求该模块,不需要像webpack那样将模块以及模块依赖的模块全部编译一次。
优缺点
vite开发阶段,打包快。
vite相关生态没有webpack完善,vite可以作为开发的辅助。
①、vite生态不及webpack,加载器、插件不够丰富
②、打包到生产环境时,vite使用传统的rollup进行打包,生产环境esbuild构建对于css和代码分割不够友好。所以,vite的优势是体现在开发阶段
③、vite首屏性能不及webpack
Webpack:浏览器发起请求,服务端将已经打包构建好的首屏内容发送给浏览器。整个过程非常普遍,没有什么可说的,不存在什么性能问题
vite:Vite在首屏方面的表现就有些差了。由于 unbundle 机制,首屏期间需要额外做以下工作:
不对源文件做合并捆绑操作,导致大量的 http 请求;
dev server 运行期间对源文件做 resolve、load、transform、parse 操作;
预构建、二次预构建操作也会阻塞首屏请求,直到预构建完成为止
如何取舍?
综合比较下来,其实还是更加偏向于vite。尽管vite在首屏、懒加载性能方面存在一些不足,但瑕不掩瑜,作为目前最火的构建工具,Vite 可以说是实至名归。而且这些问题并非不可解决,比如我们可以通过 prefetch、持久化缓存等手段做优化,相信 Vite 未来也会做出对应的改进
android开发的三大框架是:1、XUtil框架,主要有数据库模块、注解模块、网络模块、图片缓存模块;2、volley框架;3、ImageLoader框架。
1、XUtil框架
项目地址:https://github.com/wyouflf/xUtils
主要有四大模块:
(1) 数据库模块:Android中的orm框架,一行代码就可以进行增删改查;
支持事务,默认关闭;
可通过注解自定义表名,列名,外键,唯一性约束,NOT NULL约束,CHECK约束等(需要混淆的时候请注解表名和列名);
支持绑定外键,保存实体时外键关联实体自动保存或更新;
自动加载外键关联实体,支持延时加载;
支持链式表达查询,更直观的查询语义,参考下面的介绍或sample中的例子。
(2) 注解模块:android中的ioc框架,完全注解方式就可以进行UI,资源和事件绑定;
新的事件绑定方式,使用混淆工具混淆后仍可正常工作;
目前支持常用的20种事件绑定,参见ViewCommonEventListener类和包com.lidroid.xutils.view.annotation.event。
(3) 网络模块:支持同步,异步方式的请求;
支持大文件上传,上传大文件不会oom;
支持GET,POST,PUT,MOVE,COPY,DELETE,HEAD,OPTIONS,TRACE,CONNECT请求;
下载支持301/302重定向,支持设置是否根据Content-Disposition重命名下载的文件;
返回文本内容的请求(默认只启用了GET请求)支持缓存,可设置默认过期时间和针对当前请求的过期时间。
(4) 图片缓存模块:加载bitmap的时候无需考虑bitmap加载过程中出现的oom和android容器快速滑动时候出现的图片错位等现象;
支持加载网络图片和本地图片;
内存管理使用lru算法,更好的管理bitmap内存;
可配置线程加载线程数量,缓存大小,缓存路径,加载显示动画等...
2、volley
项目地址 :https://github.com/smanikandan14/Volley-demo
(1) JSON,图像等的异步下载;
(2) 网络请求的排序(scheduling)
(3) 网络请求的优先级处理
(4) 缓存
(5) 多级别取消请求
(6) 和Activity和生命周期的联动(Activity结束时同时取消所有网络请求)
3、ImageLoader框架
-
支持多线程图片加载
-
提供丰富的细节配置,比如线程池大小,HTPP请求项,内存和磁盘缓存,图片显示时的参数配置等等;
-
提供双缓存
-
支持加载过程的监听;
-
提供图片的个性化显示配置接口;