不要让开源架构代替我们的设计

现在开源的各种framework非常的多。干什么的都有。但是,是不是我们使用了这些开源framework就能够一劳永逸的解决我们的设计问题呢?我觉得答案是否定的。如果没有自己对设计和系统的理解。框架滥用就在所难免。比如说hibernate(以下简称HI),它是一个对象持久框架,他的目的非常的简单,就是提供对象持久化的手段。但是在日常的工作中,我经常看见很多人把HI用的非常的复杂,希望用HI实现一些复杂的数据库查询,似乎把HI看作了一个数据库抽象层了。使用HI,却永远不忘记SQL。我觉得这是不正确的。虽然HI的本质是ORM。但是它可不是用来替换数据库的。不要把HI当作数据库一样去操作。在设计的时候要考虑对象的差别,那些是业务对象,那些本身就是数据。如果本身就是处理数据的话,我们可以使用criteria这样的数据操作封装来操作数据。甚至,直接使用SQL语句,这时候我们的视角就发生了变化,不在是停留在业务对象上了。数据就是数据不要往对象上靠,这样更好。动不动的就搞一个POJO可不是一个好的习惯。另外,如果我们是对原有系统进行改造的话,推荐使用cayenne,apache的开源orm,有自己的管理器,可以自动从数据库中同步出pojo来。

如果是我们自己从头开始设计系统,建议不要再在数据库里面指指戳戳了。把数据库表之间的关系,改为对象之间的关系,自己写程序来维护自己对象之间的关系,推荐使用di(依赖注入),不用也可以,关键看你系统的规模。数据库中的表要尽可能的简单,要分维度和事实,以便于复用并(建议大家了解一些数据仓库的概念)减少表中的字段数。如果你采用多维结构来设计数据库的话,表中的字段不会很多。设计的好坏完全凭你多年的经验和对客户系统的了解。(分析出那些是维度,那些是事实,不是一个容易的事情,做过的人都知道)

对于框架的应用,我本身都是非常慎重的。如果我们不理解这些框架的使用背景,使用这些框架,就难免产生各种各样的问题。那么,好与不好的原则是什么?我觉得《Better, Faster, Lighter Java》一书的作者说的很好:Keep It Simple、Do One Thing,and Do It Well、Strive forTransparency。翻译过来就是:保持简单、一次做好一件事、力求透明。其实一个好的框架最起码要做到的就是透明性,有些人也管它叫非侵入性。比如spirng。(spring因此遭到批评说它其实什么也没有做,这个我有所同感)其实侵入性不是框架的问题,是我们自己设计的问题。我们应该在我们的设计中对引入的框架部分做我们自的接口,这样就可以摆脱框架侵入性的困扰。

最后我想说说我心目中的先进的web应用框架应该是什么样子的。首先它一定是REST的,所有的东西都是资源,这样可以避免session的烦恼。其次,它一定是面向服务的,也就是所谓的soa,这样可以实现松耦合,并且可以实现类似组件的功能。view部分一定是ajax的,但是也要组件化,现成的方式是EXT+buffalo。但其实也可以使用其他的界面方式,比如net的winform或者java的swing。最后还有一个对象管理器,专门负责业务对象的管理。透明的采用aop的方式,把日志、任务、权限、事物、工作流,集成进来,各个部分都是独立可配置的。可以根据需要将它们配置进我们的应用中。最后提供一种分布式的解决方案来应对可伸缩性。另外根据约定,尽量减少配置的数量和次数,尽可能的提供配置工具,而不是我们手写XML配置文件。

时间: 2024-10-12 21:27:59

不要让开源架构代替我们的设计的相关文章

解密淘宝网的开源架构

解密淘宝网的开源架构 作者:曾宪杰.2002年毕业于浙江大学计算机系.先后在中科院下属企业.先锋电子(中国)就职.积累了丰富的Windows平台.企业级系统设计经验.现任淘宝网平台架构部架构师,主要研究方向为大规模集群环境下的消息中间件设计.分布式数据层和分布式系统. 淘宝网,是一个在线商品数量突破一亿,日均成交额超过两亿元人民币,注册用户接近八千万的大型电子商务网站,是亚洲最大的购物网站.那么对于淘宝 网这样大规模的一个网站,我猜想大家一定会非常关心整个网站都采用了什么样的技术.产品和架构,也

Redis架构之防雪崩设计:网站不宕机背后的兵法

Redis架构之防雪崩设计:网站不宕机背后的兵法 原创: 付磊,张益军 高可用架构 2017-03-24 导读:互联网系统中不可避免要大量用到缓存,在缓存的使用过程中,架构师需要注意哪些问题?本文以 Redis 为例,详细探讨了最关键的 3 个问题. 一.缓存穿透预防及优化 缓存穿透是指查询一个根本不存在的数据,缓存层和存储层都不会命中,但是出于容错的考虑,如果从存储层查不到数据则不写入缓存层,如图 11-3 所示整个过程分为如下 3 步: 缓存层不命中 存储层不命中,所以不将空结果写回缓存 返

TF Live首期预告:多云时代,聊聊SDN开源架构

来了来了!TF中文社区线上直播活动"TF Live"即刻启动~ TF中文社区技术代表.瞻博网络中国区合作伙伴技术经理张建勋,将在首次直播活动中,和您一起聊聊如何面对这个多云架构时代.本期活动,由TF中文社区与SDNLAB合作举办-- 在企业未来的数字化转型过程中,如何利用开源架构产品,帮助客户实现在多云环境下的SDN网络架构设计,实现异构云平台网络的统一调度和自动化管理.我们将讨论以下问题: 为什么SDN变得越来越不灵活了? 网络硬件设备到底该怎么选?硬件SDN行不行? 我的云管平台为

敏捷开发下, 如何将需求分析,架构(软件)设计,开发与测试,一气呵成式的结合且高效的完成 ?

产品开发中,时常会发生类似如图中 "削马铃薯"的悲剧. 悲剧的发生,往往是由于我们只传递了 "要作什么功能"给开发人员.却缺乏了一个有效的且轻量级的实践,能在正式进入迭代开发前,确认开发人员是否真有能力,能将 "使用者的需求"转化为 "可执行的代码"? "场景树" 便是一结合Use Case, Domain Driven Design, UML 的轻量级可视化的敏捷实践. 经由场景树,可确认开发人员,是否已

Nginx+Lua+Redis整合实现高性能API接口 - 网站服务器 - LinuxTone | 运维专家网论坛 - 最棒的Linux运维与开源架构技术交流社区! - Powered by Discuz!

Nginx+Lua+Redis整合实现高性能API接口 - 网站服务器 - LinuxTone | 运维专家网论坛 - 最棒的Linux运维与开源架构技术交流社区! - Powered by Discuz! log.latermoon.com/

JEECG开源社区邀请有工作流设计经验的朋友

社区急需熟悉Activiti开发的朋友 社区急需熟悉微信开发的朋友 截止日期:20140615 联系人:scott (445654970) jeecg微云快速开发平台 JEECG开源社区邀请有工作流设计经验的朋友

遗留系统SOA之(2)——SOA架构基础概念与设计框架

SOA的设计框架 设计框架与架构相关的概念紧密相连,原则.模式和架构始终是与设计共舞的. SOA服务设计的原则中记录了一个基础的设计框架: 设计特性(Design Characteristic)——由设计产生的软件程序或技术架构的属性.它可以是任何具体的质量要求,比如程序组件化,功能粒度的粗细等. 设计原则(Design Principles)——一个针对具体设计目标且被业界接受的实践方式.面向服务的设计范式包括了一个以实现面向服务计算为目的的设计原则集合. 设计模式(Design Patter

架构师内功心法之设计原则

一.架构师内功心法之设计原则 1.为什么要学习软件架构设计原则 1.1.课程目标 通过对节课内容的学习,了解设计原则的重要性. 掌握七大设计原则的具体内容. 1.2.内容定位 学习设计原则,学习设计模式的基础.在实际开发过程中,并不是一定要求所有代码都遵循设计原则,我们要考虑人力.时间.成本.质量,不是刻意追求完美,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助我们设计出更加优雅的代码结构. 1.3.七大设计原则 [x] 第1章 Open-Closed Principle 开闭原则 [x

关于架构的优化和设计,架构师必须悟透的事情

近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”:关于如何设计出灵活.高可用性以及能够快速适应变化的系统架构,我们依旧还有很大的发挥空间.本文会介绍关于如何构建前沿的.易维护的.安全的架构的几个要点,同时你也可以把它当作系统设计的准则或者用它来验证现有的架构是否合理. 就像我们经常所说的:没有最好的架构,只有最合适的架构.一个好的架构师,可以根据具体的需求.所拥有的资源等因素综合考虑而设计出最优的架构方案.特别是现在,业务的飞速变化.数据无