34 个解决方案
#1
用razor的话就是全端,只用webapi的话就是后端
#3
asp.net中razor是主流啊,那还不如后端用nodejs
#4
是不是“只用 webapi”的程序员呢?
#5
这就好像是 winform、wpf 论坛里出现了一个只用 EF 的程序员。
但是即使是只用 EF,也并不改变 winform、wpf 的前端桌面程序开发性质。
但是即使是只用 EF,也并不改变 winform、wpf 的前端桌面程序开发性质。
#6
如果你面对一个 asp.net 产品开发,你就用这个工具来开发出来产品。这个时候不是纠结名词儿跳到别的东西上面去,而是要看你用 asp.net 能做什么实际的产品出来。
学各种各样时髦技术,而一遇到复杂的用户需求,就找别的工具去看看有没有可抄来的新的代码,那就等于是逃避开发责任,不管用什么编程语言其实一旦遇到真正的实践的挑战则都会逃避。
#7
怪不得asp.net慢,mvc用的是razor是在服务器端执行的
#8
或许在chakra上开发nodejs,会比asp.net更好,也更有意义
#9
每天喷来喷去 有意思?
这么慢你还纠结干嘛,赶快转行啊..
二线城市卖个手抓饼 每天早上工作3小时 也能过万.
这么慢你还纠结干嘛,赶快转行啊..
二线城市卖个手抓饼 每天早上工作3小时 也能过万.
#10
asp.net 中其实混杂了许多部分,你不需要 razor,就不要调用什么 controller,而用其它的东西不就行了嘛!
你说只要是实现了 razor 语法解析的编程语言/平台就慢了,我猜你有更好的不用 razor 甚至不用 mvc 的服务器端使用方式。不妨描述出来,看看如何能更好地支持程序员搞复杂 web 应用的开发工作。
#11
无论如何,评估一个工具都是从实际应用经验和众多项目的愿景出发的,不是从1、2个名词儿去“抠字眼儿”出发的。所以所有东西都有其合理的解释、有其自己最适合的场景。关键是你设定的应用的场景要让别人理解。
比如说你说 asp.net 程序员不搞页面设计、不管用户交互操作需求,那么这时候 asp.net 是干什么呢?这时候难道不是 windows service 更合适进行真正专业的服务器开发吗?还要 asp.net 干什么?
比如说你说 asp.net 程序员不搞页面设计、不管用户交互操作需求,那么这时候 asp.net 是干什么呢?这时候难道不是 windows service 更合适进行真正专业的服务器开发吗?还要 asp.net 干什么?
#12
其实我们抛开编程平台,先来理解“人”的问题,然后再来考虑技术,就会用好开发工具。我们说 asp.net 的时候几乎都是说如何更好地开发 web 应用。我自己尤其是重点来说的是企业级 web 应用设计开发方面。(而且我还假设许多程序员是程序设计师,能在小项目上独当一面搞软件设计,而不是简单地抄代码来的)
从需求场景出发,比较容易深入技术核心价值。比如说你说抛开 razor,那么回到有 razor 之前的核心价值和目标去,就容易理解为什么要抛开它。反之如果逃避前端设计开发需求,那么其实就算是 asp.net 再增加一堆的抄 java 和其它工具的机制,也等于零,它没有抄到未来核心技术而是抄前几年人家已经玩儿剩下、觉得可以公开出来的过时技术。
从需求场景出发,比较容易深入技术核心价值。比如说你说抛开 razor,那么回到有 razor 之前的核心价值和目标去,就容易理解为什么要抛开它。反之如果逃避前端设计开发需求,那么其实就算是 asp.net 再增加一堆的抄 java 和其它工具的机制,也等于零,它没有抄到未来核心技术而是抄前几年人家已经玩儿剩下、觉得可以公开出来的过时技术。
#13
我并不在乎前端,你在这里混。自然知道我说过我不怎么在乎前端。
项目开发时多工种配合,虽然不在乎前端,但你的提供对人家友好的方案,技术选型和方向。你写个东西就你自己方便,其他人都别扭,前端别扭,维护别扭,交互别扭,那就是你的工作不到位了
同样现在这些在乎前端的人,都是历史遗留问题。XXX园喜欢搞套路,这些套路打起来都是一套一套的,他们美其名曰“印度化”“流水线化”“软件工厂化”,写项目都一套标准的“太极拳24式”,自然前端这种东西在这种思维模式下,他是跟整个系统形成的完整的一个套路,你建立一个项目一行代码都没写,整个前端,后端,服务,仓储都在那里。你就算不玩前端,他也在那24式里摆着
项目开发时多工种配合,虽然不在乎前端,但你的提供对人家友好的方案,技术选型和方向。你写个东西就你自己方便,其他人都别扭,前端别扭,维护别扭,交互别扭,那就是你的工作不到位了
同样现在这些在乎前端的人,都是历史遗留问题。XXX园喜欢搞套路,这些套路打起来都是一套一套的,他们美其名曰“印度化”“流水线化”“软件工厂化”,写项目都一套标准的“太极拳24式”,自然前端这种东西在这种思维模式下,他是跟整个系统形成的完整的一个套路,你建立一个项目一行代码都没写,整个前端,后端,服务,仓储都在那里。你就算不玩前端,他也在那24式里摆着
#14
我感觉好纠结啊
#15
就像你自己也不一样么
研究个微服务,也是一套一套的,非要这样,非要那样
而我们也不在乎,只要他足够友好,满足要求,能扩展,方便运维,我们不使用套路也行
比如微服务--他能被快速部署,独立配置,自主发现,正交隔离设计,容易做逻辑上的扩展,也容易做物理上的扩展,这就达到目标了,我们也不一定就的是你说那些东西
快速部署:不用docker,用window servcie不行么
服务发现:我自己用upnp不行么?
协议提供:我自己用双工sokect,用avro封包不行么。不够rest?那我owin self webapi,singrlR,webSocket不行么。
独立配置:我自己nosql,自己维护自己的配置不行么?或者用zookeeper分发同步上层中线的配置不行么?
总之,就是那句话。只要你放弃这种无聊的天天行而上的用几个名词踩这个吹那个的幼稚行为,打算做个卓有成效的实用主义程序员,你就发现这个东西其实你想怎么做都成,别这个慢那个慢,他玩套路的慢,不代表实用主义一击致命的慢
研究个微服务,也是一套一套的,非要这样,非要那样
而我们也不在乎,只要他足够友好,满足要求,能扩展,方便运维,我们不使用套路也行
比如微服务--他能被快速部署,独立配置,自主发现,正交隔离设计,容易做逻辑上的扩展,也容易做物理上的扩展,这就达到目标了,我们也不一定就的是你说那些东西
快速部署:不用docker,用window servcie不行么
服务发现:我自己用upnp不行么?
协议提供:我自己用双工sokect,用avro封包不行么。不够rest?那我owin self webapi,singrlR,webSocket不行么。
独立配置:我自己nosql,自己维护自己的配置不行么?或者用zookeeper分发同步上层中线的配置不行么?
总之,就是那句话。只要你放弃这种无聊的天天行而上的用几个名词踩这个吹那个的幼稚行为,打算做个卓有成效的实用主义程序员,你就发现这个东西其实你想怎么做都成,别这个慢那个慢,他玩套路的慢,不代表实用主义一击致命的慢
#16
当你开发 web 交互式应用系统时,这个时候用户谁管你用什么数据库?是使用直接的 ashx 还是 web api 来读取 http post 方式?后台有没有用什么数据库系统?用户首先关心的就是你的 web 应用好用不好用、快不快、稳定不稳定,能不能跨平台.....
你使用 asp.net 干什么?总不能只是为了在 csdn 学习而好几年都不开放新产品吧?总是要用项目和产品来检验的。
你使用 asp.net 干什么?总不能只是为了在 csdn 学习而好几年都不开放新产品吧?总是要用项目和产品来检验的。
#17
web 应用的开发都是从web 前端出发,然后打通一个链条,适应千变万化的重构需求。基本上一个设计师就算是不亲自写每个代码文件,起码要能了解形成进度的所有细节。而假设把精力放在底层、仅仅放在自己感兴趣的那点地方,就不行了。一个好的设计师,对于自己不感兴趣的东西,只要用户需要,他也会重点地培养自己的兴趣,最重设计出来架构。
#18
侧重后台,前端至少了解吧,最简单的,有很多前段东西是由后台生成的,包括js,jq这些
#19
比如说有一个“树状的视图展示”,那么某一个节点的下一级子树是展开的、还是折叠的?节点上要不要动态地用“徽章符号”来提示子树的数目呢?如何动态显示节点和节点之间的关联关系(用不同的线形)呢?
asp.net 程序员可以推卸说公司应该另外招聘好几种开发人员。但是那是什么样的公司?你现在真的是呆在这样的公司里吗?那么可真的是很清闲的工作。
不负责网页开发的 asp.net 的程序员肯定是没有前途的。只不过是你能推脱多少,公司有没有精力要求产品面向 html5 之类的进行转变,只是这种程度不同罢了。
asp.net 程序员可以推卸说公司应该另外招聘好几种开发人员。但是那是什么样的公司?你现在真的是呆在这样的公司里吗?那么可真的是很清闲的工作。
不负责网页开发的 asp.net 的程序员肯定是没有前途的。只不过是你能推脱多少,公司有没有精力要求产品面向 html5 之类的进行转变,只是这种程度不同罢了。
#20
比如说你跟公司说你只关心如何在数据库中增删改查树状视图的数据部分,然后你要求你的工资跟公司招聘的其它技术人员的工资一样高,甚至你认为工资要求更高。
这样不仅仅是 asp.net 工具其实就没多大做用了,技术工具都是很次要的东西,关键是地是“人”的问题,这个“后台”职位会被那些能够垂直地负责一些小模块的新培训出来的程序员所取代。
这样不仅仅是 asp.net 工具其实就没多大做用了,技术工具都是很次要的东西,关键是地是“人”的问题,这个“后台”职位会被那些能够垂直地负责一些小模块的新培训出来的程序员所取代。
#21
就现在来说,大多的web开发,都需要会点前端。
包括了解一些与时俱进的前端Js框架,jquery,anglarjs等等。
其实说白了。这就像你一个搞后台的,不了解sql总归也是满奇葩的
包括了解一些与时俱进的前端Js框架,jquery,anglarjs等等。
其实说白了。这就像你一个搞后台的,不了解sql总归也是满奇葩的
#22
#23
上面说了,程序员界有两组人,一组人轻形式,重实效,另一组人重形式,轻实效
当然他们也会融合,比如我自己现在的团队就有两个团队。我手上的带的前一组,另一个兄弟带的是另一组
在另一个组里就流行形式主义,比如他们的架子是从XXX园里某个号称DDD的大牛搞出来的13层的架子(相信很多人都知道我说的是谁),但是随着两组人马的融合,他们的那个架子现在是7层,虽然依旧累赘,不过已经好了很多了
而我自己这一组也一样两组融合的,我则没有固定的架子(其实也是有架子,这是并不想形式主义那样必须得如此),随着融合我这形成的并不是架子,而是 framework,我这边也会有一些相对形式主义的脚手架
如果是慢,其实基本上也就是使用形式主义的慢,因为他们那是一整套的动作,他们没办法做适应性的调整,他只针对一些特定的东西,换成其他不适配的场景,使用架子的人就更如此了
当然他们也会融合,比如我自己现在的团队就有两个团队。我手上的带的前一组,另一个兄弟带的是另一组
在另一个组里就流行形式主义,比如他们的架子是从XXX园里某个号称DDD的大牛搞出来的13层的架子(相信很多人都知道我说的是谁),但是随着两组人马的融合,他们的那个架子现在是7层,虽然依旧累赘,不过已经好了很多了
而我自己这一组也一样两组融合的,我则没有固定的架子(其实也是有架子,这是并不想形式主义那样必须得如此),随着融合我这形成的并不是架子,而是 framework,我这边也会有一些相对形式主义的脚手架
如果是慢,其实基本上也就是使用形式主义的慢,因为他们那是一整套的动作,他们没办法做适应性的调整,他只针对一些特定的东西,换成其他不适配的场景,使用架子的人就更如此了
#24
我们天天在这里回复问题,其实也是因为我们是重实效的程序员
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
#25
asp.net原来流行的是webform,标准的服务器端控件,这种自然没什么前端的概念,现在流行的mvc虽然用razor,但主流的还是应该作为一个代理,具体的交给客户端的javascript来处理
#26
我们天天在这里回复问题,其实也是因为我们是重实效的程序员
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
看你平时不怎么编程的,最多用用framework,那我就不和你多说了,你的逻辑真是搞笑,我问个微服务的问题,就变成我研究微服务了,还有什么前端重不重要,我看上面的sp1234就很在乎
#27
相比什么asp.net core,我对chakra上的nodejs更有兴趣
#28
又见大神来车轮战,
#29
能写前端吧,.用xml写的。。。
#30
这年头不会前端能找到工作?
#31
asp.net是一套完整的web开发工具集,并不楼主说的所谓后端技术,
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
#32
。net 是后端
#33
asp.net是一套完整的web开发工具集,并不楼主说的所谓后端技术,
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
ajax和asp.net有什么关系,asp.net还能写客户端应用啊
#34
ajax和asp.net有什么关系,asp.net还能写客户端应用啊
microsoft Ajax library 是asp.net4.0的一部分,
你不需要添加额外的引用,就可以直接使用微软的JS库的各种强大的客户端API
#1
用razor的话就是全端,只用webapi的话就是后端
#2
#3
用razor的话就是全端,只用webapi的话就是后端
asp.net中razor是主流啊,那还不如后端用nodejs
#4
是不是“只用 webapi”的程序员呢?
#5
这就好像是 winform、wpf 论坛里出现了一个只用 EF 的程序员。
但是即使是只用 EF,也并不改变 winform、wpf 的前端桌面程序开发性质。
但是即使是只用 EF,也并不改变 winform、wpf 的前端桌面程序开发性质。
#6
asp.net中razor是主流啊,那还不如后端用nodejs
如果你面对一个 asp.net 产品开发,你就用这个工具来开发出来产品。这个时候不是纠结名词儿跳到别的东西上面去,而是要看你用 asp.net 能做什么实际的产品出来。
学各种各样时髦技术,而一遇到复杂的用户需求,就找别的工具去看看有没有可抄来的新的代码,那就等于是逃避开发责任,不管用什么编程语言其实一旦遇到真正的实践的挑战则都会逃避。
#7
是不是“只用 webapi”的程序员呢?
怪不得asp.net慢,mvc用的是razor是在服务器端执行的
#8
或许在chakra上开发nodejs,会比asp.net更好,也更有意义
#9
每天喷来喷去 有意思?
这么慢你还纠结干嘛,赶快转行啊..
二线城市卖个手抓饼 每天早上工作3小时 也能过万.
这么慢你还纠结干嘛,赶快转行啊..
二线城市卖个手抓饼 每天早上工作3小时 也能过万.
#10
是不是“只用 webapi”的程序员呢?
怪不得asp.net慢,mvc用的是razor是在服务器端执行的
asp.net 中其实混杂了许多部分,你不需要 razor,就不要调用什么 controller,而用其它的东西不就行了嘛!
你说只要是实现了 razor 语法解析的编程语言/平台就慢了,我猜你有更好的不用 razor 甚至不用 mvc 的服务器端使用方式。不妨描述出来,看看如何能更好地支持程序员搞复杂 web 应用的开发工作。
#11
无论如何,评估一个工具都是从实际应用经验和众多项目的愿景出发的,不是从1、2个名词儿去“抠字眼儿”出发的。所以所有东西都有其合理的解释、有其自己最适合的场景。关键是你设定的应用的场景要让别人理解。
比如说你说 asp.net 程序员不搞页面设计、不管用户交互操作需求,那么这时候 asp.net 是干什么呢?这时候难道不是 windows service 更合适进行真正专业的服务器开发吗?还要 asp.net 干什么?
比如说你说 asp.net 程序员不搞页面设计、不管用户交互操作需求,那么这时候 asp.net 是干什么呢?这时候难道不是 windows service 更合适进行真正专业的服务器开发吗?还要 asp.net 干什么?
#12
其实我们抛开编程平台,先来理解“人”的问题,然后再来考虑技术,就会用好开发工具。我们说 asp.net 的时候几乎都是说如何更好地开发 web 应用。我自己尤其是重点来说的是企业级 web 应用设计开发方面。(而且我还假设许多程序员是程序设计师,能在小项目上独当一面搞软件设计,而不是简单地抄代码来的)
从需求场景出发,比较容易深入技术核心价值。比如说你说抛开 razor,那么回到有 razor 之前的核心价值和目标去,就容易理解为什么要抛开它。反之如果逃避前端设计开发需求,那么其实就算是 asp.net 再增加一堆的抄 java 和其它工具的机制,也等于零,它没有抄到未来核心技术而是抄前几年人家已经玩儿剩下、觉得可以公开出来的过时技术。
从需求场景出发,比较容易深入技术核心价值。比如说你说抛开 razor,那么回到有 razor 之前的核心价值和目标去,就容易理解为什么要抛开它。反之如果逃避前端设计开发需求,那么其实就算是 asp.net 再增加一堆的抄 java 和其它工具的机制,也等于零,它没有抄到未来核心技术而是抄前几年人家已经玩儿剩下、觉得可以公开出来的过时技术。
#13
我并不在乎前端,你在这里混。自然知道我说过我不怎么在乎前端。
项目开发时多工种配合,虽然不在乎前端,但你的提供对人家友好的方案,技术选型和方向。你写个东西就你自己方便,其他人都别扭,前端别扭,维护别扭,交互别扭,那就是你的工作不到位了
同样现在这些在乎前端的人,都是历史遗留问题。XXX园喜欢搞套路,这些套路打起来都是一套一套的,他们美其名曰“印度化”“流水线化”“软件工厂化”,写项目都一套标准的“太极拳24式”,自然前端这种东西在这种思维模式下,他是跟整个系统形成的完整的一个套路,你建立一个项目一行代码都没写,整个前端,后端,服务,仓储都在那里。你就算不玩前端,他也在那24式里摆着
项目开发时多工种配合,虽然不在乎前端,但你的提供对人家友好的方案,技术选型和方向。你写个东西就你自己方便,其他人都别扭,前端别扭,维护别扭,交互别扭,那就是你的工作不到位了
同样现在这些在乎前端的人,都是历史遗留问题。XXX园喜欢搞套路,这些套路打起来都是一套一套的,他们美其名曰“印度化”“流水线化”“软件工厂化”,写项目都一套标准的“太极拳24式”,自然前端这种东西在这种思维模式下,他是跟整个系统形成的完整的一个套路,你建立一个项目一行代码都没写,整个前端,后端,服务,仓储都在那里。你就算不玩前端,他也在那24式里摆着
#14
我感觉好纠结啊
#15
就像你自己也不一样么
研究个微服务,也是一套一套的,非要这样,非要那样
而我们也不在乎,只要他足够友好,满足要求,能扩展,方便运维,我们不使用套路也行
比如微服务--他能被快速部署,独立配置,自主发现,正交隔离设计,容易做逻辑上的扩展,也容易做物理上的扩展,这就达到目标了,我们也不一定就的是你说那些东西
快速部署:不用docker,用window servcie不行么
服务发现:我自己用upnp不行么?
协议提供:我自己用双工sokect,用avro封包不行么。不够rest?那我owin self webapi,singrlR,webSocket不行么。
独立配置:我自己nosql,自己维护自己的配置不行么?或者用zookeeper分发同步上层中线的配置不行么?
总之,就是那句话。只要你放弃这种无聊的天天行而上的用几个名词踩这个吹那个的幼稚行为,打算做个卓有成效的实用主义程序员,你就发现这个东西其实你想怎么做都成,别这个慢那个慢,他玩套路的慢,不代表实用主义一击致命的慢
研究个微服务,也是一套一套的,非要这样,非要那样
而我们也不在乎,只要他足够友好,满足要求,能扩展,方便运维,我们不使用套路也行
比如微服务--他能被快速部署,独立配置,自主发现,正交隔离设计,容易做逻辑上的扩展,也容易做物理上的扩展,这就达到目标了,我们也不一定就的是你说那些东西
快速部署:不用docker,用window servcie不行么
服务发现:我自己用upnp不行么?
协议提供:我自己用双工sokect,用avro封包不行么。不够rest?那我owin self webapi,singrlR,webSocket不行么。
独立配置:我自己nosql,自己维护自己的配置不行么?或者用zookeeper分发同步上层中线的配置不行么?
总之,就是那句话。只要你放弃这种无聊的天天行而上的用几个名词踩这个吹那个的幼稚行为,打算做个卓有成效的实用主义程序员,你就发现这个东西其实你想怎么做都成,别这个慢那个慢,他玩套路的慢,不代表实用主义一击致命的慢
#16
当你开发 web 交互式应用系统时,这个时候用户谁管你用什么数据库?是使用直接的 ashx 还是 web api 来读取 http post 方式?后台有没有用什么数据库系统?用户首先关心的就是你的 web 应用好用不好用、快不快、稳定不稳定,能不能跨平台.....
你使用 asp.net 干什么?总不能只是为了在 csdn 学习而好几年都不开放新产品吧?总是要用项目和产品来检验的。
你使用 asp.net 干什么?总不能只是为了在 csdn 学习而好几年都不开放新产品吧?总是要用项目和产品来检验的。
#17
web 应用的开发都是从web 前端出发,然后打通一个链条,适应千变万化的重构需求。基本上一个设计师就算是不亲自写每个代码文件,起码要能了解形成进度的所有细节。而假设把精力放在底层、仅仅放在自己感兴趣的那点地方,就不行了。一个好的设计师,对于自己不感兴趣的东西,只要用户需要,他也会重点地培养自己的兴趣,最重设计出来架构。
#18
侧重后台,前端至少了解吧,最简单的,有很多前段东西是由后台生成的,包括js,jq这些
#19
比如说有一个“树状的视图展示”,那么某一个节点的下一级子树是展开的、还是折叠的?节点上要不要动态地用“徽章符号”来提示子树的数目呢?如何动态显示节点和节点之间的关联关系(用不同的线形)呢?
asp.net 程序员可以推卸说公司应该另外招聘好几种开发人员。但是那是什么样的公司?你现在真的是呆在这样的公司里吗?那么可真的是很清闲的工作。
不负责网页开发的 asp.net 的程序员肯定是没有前途的。只不过是你能推脱多少,公司有没有精力要求产品面向 html5 之类的进行转变,只是这种程度不同罢了。
asp.net 程序员可以推卸说公司应该另外招聘好几种开发人员。但是那是什么样的公司?你现在真的是呆在这样的公司里吗?那么可真的是很清闲的工作。
不负责网页开发的 asp.net 的程序员肯定是没有前途的。只不过是你能推脱多少,公司有没有精力要求产品面向 html5 之类的进行转变,只是这种程度不同罢了。
#20
比如说你跟公司说你只关心如何在数据库中增删改查树状视图的数据部分,然后你要求你的工资跟公司招聘的其它技术人员的工资一样高,甚至你认为工资要求更高。
这样不仅仅是 asp.net 工具其实就没多大做用了,技术工具都是很次要的东西,关键是地是“人”的问题,这个“后台”职位会被那些能够垂直地负责一些小模块的新培训出来的程序员所取代。
这样不仅仅是 asp.net 工具其实就没多大做用了,技术工具都是很次要的东西,关键是地是“人”的问题,这个“后台”职位会被那些能够垂直地负责一些小模块的新培训出来的程序员所取代。
#21
就现在来说,大多的web开发,都需要会点前端。
包括了解一些与时俱进的前端Js框架,jquery,anglarjs等等。
其实说白了。这就像你一个搞后台的,不了解sql总归也是满奇葩的
包括了解一些与时俱进的前端Js框架,jquery,anglarjs等等。
其实说白了。这就像你一个搞后台的,不了解sql总归也是满奇葩的
#22
#23
上面说了,程序员界有两组人,一组人轻形式,重实效,另一组人重形式,轻实效
当然他们也会融合,比如我自己现在的团队就有两个团队。我手上的带的前一组,另一个兄弟带的是另一组
在另一个组里就流行形式主义,比如他们的架子是从XXX园里某个号称DDD的大牛搞出来的13层的架子(相信很多人都知道我说的是谁),但是随着两组人马的融合,他们的那个架子现在是7层,虽然依旧累赘,不过已经好了很多了
而我自己这一组也一样两组融合的,我则没有固定的架子(其实也是有架子,这是并不想形式主义那样必须得如此),随着融合我这形成的并不是架子,而是 framework,我这边也会有一些相对形式主义的脚手架
如果是慢,其实基本上也就是使用形式主义的慢,因为他们那是一整套的动作,他们没办法做适应性的调整,他只针对一些特定的东西,换成其他不适配的场景,使用架子的人就更如此了
当然他们也会融合,比如我自己现在的团队就有两个团队。我手上的带的前一组,另一个兄弟带的是另一组
在另一个组里就流行形式主义,比如他们的架子是从XXX园里某个号称DDD的大牛搞出来的13层的架子(相信很多人都知道我说的是谁),但是随着两组人马的融合,他们的那个架子现在是7层,虽然依旧累赘,不过已经好了很多了
而我自己这一组也一样两组融合的,我则没有固定的架子(其实也是有架子,这是并不想形式主义那样必须得如此),随着融合我这形成的并不是架子,而是 framework,我这边也会有一些相对形式主义的脚手架
如果是慢,其实基本上也就是使用形式主义的慢,因为他们那是一整套的动作,他们没办法做适应性的调整,他只针对一些特定的东西,换成其他不适配的场景,使用架子的人就更如此了
#24
我们天天在这里回复问题,其实也是因为我们是重实效的程序员
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
#25
asp.net原来流行的是webform,标准的服务器端控件,这种自然没什么前端的概念,现在流行的mvc虽然用razor,但主流的还是应该作为一个代理,具体的交给客户端的javascript来处理
#26
我们天天在这里回复问题,其实也是因为我们是重实效的程序员
我们有自己的framework,我们不重视固定形式,我们根据项目要求去挑选合适的脚手架,我们做的快,运行快,维护方便,扩展方便。所以我们有大把时间在网上“闲逛”,去发现新东西,新想法,有意思的思路
而号称软件工厂的反而没这么多时间了,因为他的形式主义注定他必须限制自己的手脚,当不合适的时候也注定他的去缝缝补补,甚至强行去适配那个场景,这样反而做的不快,别扭。强行适配的结果往往也不容易扩展,不容易维护,甚至他不同项目都是多个修补过“定制版”,跟谈不上什么复用
看你平时不怎么编程的,最多用用framework,那我就不和你多说了,你的逻辑真是搞笑,我问个微服务的问题,就变成我研究微服务了,还有什么前端重不重要,我看上面的sp1234就很在乎
#27
相比什么asp.net core,我对chakra上的nodejs更有兴趣
#28
又见大神来车轮战,
#29
能写前端吧,.用xml写的。。。
#30
这年头不会前端能找到工作?
#31
asp.net是一套完整的web开发工具集,并不楼主说的所谓后端技术,
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
#32
。net 是后端
#33
asp.net是一套完整的web开发工具集,并不楼主说的所谓后端技术,
asp.net支持纯js客户端的web应用开发,也支持纯服务端的web应用开发,
当然,也就支持前后端分离模式的web应用开发
asp.net提供了一个功能丰富的JS框架,可以简化客户端编程,诸如:
1.对基本类型的扩展;
2.高级面向对象编程的支持,比如:class,interface,namsspace,inherit
3.web通信api,json处理api,
4.基于事件和控件的UI开发模式的支持
......不一一列举,更多细节参见MSDN:
https://msdn.microsoft.com/zh-cn/library/bb397536.aspx
ajax和asp.net有什么关系,asp.net还能写客户端应用啊
#34
ajax和asp.net有什么关系,asp.net还能写客户端应用啊
microsoft Ajax library 是asp.net4.0的一部分,
你不需要添加额外的引用,就可以直接使用微软的JS库的各种强大的客户端API