×

java三层架构 c static

java三层架构(在java三层架构中,单例的service层为什么不使用静态static方式来实现)

admin admin 发表于2023-10-27 08:52:58 浏览1520 评论0

抢沙发发表评论

本文目录

在java三层架构中,单例的service层为什么不使用静态static方式来实现

非static 便于管理。

J2EE常用的技术是ioc和aop.它们本质上都是用的反射或者动态代理这两种技术。而这两种技术操作对象都是非static 实例。

举个例子:你模仿依赖注入给一个实例的属性set值,发现set方法不能是static 。

php和java相比,应该往哪个方向发展

谢谢邀请!

首先,如果抛开应用场景来探讨编程语言是不合理的,另外编程语言的孰优孰劣也有不同的判断角度,所以需要从多个维度来进行分析。

Java和PHP语言都是目前IT行业内被广泛采用的编程语言,目前Java语言的应用场景集中在Web开发、大数据开发、Android开发和后端服务开发领域,而PHP语言则比较专注,主要应用于Web开发,但是PHP在Web开发领域的份额比较大,所以PHP的程序员基数也非常大。

从应用的范围来看,无疑Java语言具有一定的优势,而且Java语言凭借稳定的性能表现和较强的扩展能力是不少大型互联网平台的重要选择,从这个角度来看,似乎Java语言更有优势一些。

但是Java语言的问题也不少,比如Java在语法结构上没有PHP简洁,这直接导致了采用Java方案会加长开发周期,所以不少中小型项目往往会更愿意采用PHP语言。从程序员的角度来说,没有人愿意“复杂”,由于PHP语言在语法结构上的优势,使得PHP程序员对于PHP语言的“忠诚度”是比较高的,这就是为什么经常听说从Java开发转到PHP,或者从Java开发转到Python,但是很少听说PHP程序员转到Java。

当前在开发领域有明显的多极化发展趋势,从早期的前后端划分到现在的“大前端”概念、全栈开发概念、资源接口概念等都在各自的应用场景下得到了发展。对于编程语言的发展来说,如何迎合技术发展趋势是非常重要的。从发展趋势来看,未来PHP在Web开发领域将依然是最为重要的编程语言之一,而Java语言未来虽然依然会有广泛的应用,但是随着Python、JavaScript和Go等语言的发展,Java语言的应用场景会得到一定程度的压缩。

最后,如果要从事Web开发,那么就选择PHP,如果从事大数据和后端开发就选择Java。

我从事互联网行业多年,目前也在带计算机专业的研究生,主要的研究方向集中在大数据和人工智能领域,我会陆续写一些关于互联网技术方面的文章,感兴趣的朋友可以关注我,相信一定会有所收获。

如果有互联网方面的问题,或者考研方面的问题,都可以咨询我,谢谢!

资深Java架构师经验之谈,项目的”烂”和”好”如何衡量和定义

作为一个资深的互联网从业者,我要非常负责任的说,项目的好坏最根本的在于市场,而不是单纯的技术。

不可否认,技术对于一个产品来说非常重要,曾几何时,我也是非常的追求技术上的“高端”从而忘记了产品与市场、时间上的问题。因此,由于技术上的某些原因,导致了项目的延期甚至上线后发生一些比较严重的Bug。

后来,随着工作的时间越来越长,对于技术和产品的观念慢慢发生着改变。后来,我在一次工作中的经历,让我确实的认识到了,技术是为产品和市场服务的。

那时,我作为一个项目的负责人,全权对项目负责,为了让项目能够更快的上线,我使用了最简单的技术方案,使用最少的人力,让项目快速的上线了。由于项目的发展比较快,后期还上了物联网设备,使得在不断的迭代过程中,曾经的架构慢慢的无法支撑业务的增长。

这时,就面临需要重构了,而这个时期,团队有两个声音,一个觉得应该使用领域驱动设计(DDD)和查询和命令职责分离(CQRS)来重构,理由是因为,我们团队曾经对DDD有一定的研究,而且经过这么长时间,对于业务的理解已经非常深了,使用DDD能够很好的锻炼团队,并且让产品的技术底蕴很深厚。另一个是觉得,我们应该在服务化上做更多的优化,不改变现有的底层架构。

当然,我个人是不建议用DDD的,因为我当时自己对DDD的理解都不深,我相信团队大部分的人对于DDD都是一知半解,潜在的风险太大了。

但是,老板估计对现有的架构不是很满意,加上另一个技术的负责人大力的推荐DDD,因此最终就使用了这个方案,这导致使用了大量的人力在项目的重构上,对于业务上的迭代速度变得相当的慢。2个半月以后,业务的压力直接导致了这次重构的版本夭折了。

这次经历,让我在技术选型的时候更加的谨慎了,尽量不去使用自己不熟悉的技术方案,技术的创新前,需要做大量的实验。

再后来,我遇到了一个丰田的技术人员,他是做丰田的物流系统的。丰田的物流体系是全球数一数二的,也是少有的能够做到准时制物流的公司。按道理,这样庞大的系统,架构应该是非常复杂的才对。

但是,我在详细的了解后发现,并不是这样的。丰田的物流系统使用

.NET

做的,基础的三层架构,连MVC都没有使用,甚至连分布式缓存都没有使用,性能差了,就加服务器。

丰田本来就不是一个互联网公司,是全球最大的汽车制造商,自然不愿意花太多钱养太多技术人员,但是服务器多花点钱是没关系的。这样技术方案其实是最适合丰田的,语气花一年上千万养一大群高端的技术人员,不如花几百万还买服务器呢。

因此,项目的好坏其实更多的还是看看这个项目是不是符合用户的需求,能不能解决用户的痛点,技术上是不是最适合产品的定位。并不是技术越高端就是越好的,而作为架构师,除了了解技术外,还需要了解业务,只有明白了业务的发展,才能够做出最适合的架构。