架构之路(五):忘记数据库

  • 时间:
  • 浏览:0
  • 来源:大发5分排列3_大发5分排列3官方

好在我终于出現来了。

惯例说我的项目进展:

1、写文档写到吐……

2、重构累成了狗……

本计划发布了新版本再写这篇博客的,但我我人太好不才能再拖了。博客系列接下来,就进入项目的具体开发了,代码还乱成一堆,啊……

……

真正的对象数据库!快出来啊,求你了……

是的,刚刚可能抽象,类很可能比表才能多。刚刚,有于抽象,在一群人进行架构、设计、沟通的刚刚,才都都还可不可以暂时的拖累所以有细节。比如,一群人才都都还可不可以说,“文章被评论刚刚,文章作者的积分加10分”,這個刚刚,一群人就不考虑文章有所以有种:博客、新闻、问答、评论……,也不考虑积分增加是直接改积分总分呢,还是加带第第一根积分记录,可才都都还可不可以同步……。可才都都还可不可以表,你为社 么说?

所以有,所以有系统,即使勉强弄出一个 业务层,也“薄”得不像话,像一层保鲜袋一样,你才都都还可不可以有三种把它立即撕掉的强烈的冲动。

需求是:记录文章(Article)的浏览数(ViewCount)。每当文章被阅读(View)一次,浏览数加一。

是的,忘掉数据库是没人没人——尤其是对于一群人哪几种老人来说。可能浸淫sql数十年的高手,你我想忘掉它?青春恋爱物语写小说啊,张无忌学太极啊?

数据库?就先不管它吧。

一群人这里,也不把复杂度推给了Map团队、ORM工具开发商和DBA。

可能一群人要和客户谈需求啊,典型的是领域驱动,要和客户/领域专家找到“一起去的语言”,這個起去的语言是哪几种?是表社会形态?估计可能开发的是一个 财务会计系统,这还是可行的——估计早期的系统大多也不财务报表类系统?说不定还青春恋爱物语原本。为哪几种面向对象从Java现在始于流行,Java是虚拟机,才都都还可不可以用在微波炉报警器累似 里边的,底层数据社会形态才都都还可不可以删改脱离数据库啊!.NET做哪几种起家的,就报表啊!呵呵。

“我我希望看到需求,脑子里马上也不数据库也不表。”

看到這個需求,你首先想到的是哪几种?是删改还会:

步子小所以,做成两层架构,估计所以问題图片都没人,一群人都能接受;步子再大所以,就得上ORM,可惜微软当时还没条件支持。所以有就搞出了没人个不明不白稀里糊涂的概念出来,折磨了我了吗了吗……

一群人还是回到大方向上来,为哪几种要没人做?换言之,“面向数据库”有哪几种问題图片,可能说“面向对象”有哪几种好处?

究竟为社 么从硬盘里存取(所谓的“持久化”),刚刚再说。我连用哪几种进行持久化都我想知道,现在为社 么考虑?但有第第一根,反正不让用关系数据库,估计是用nosql吧……

写在这里很搞笑,但事实也不原本的。在性能篇,是我不好,我想写高性能的代码,你也不抢了人家的饭碗,就這個意思。UI都把DBA的活儿干了,人家吃哪几种?你代码都写成04001010101010二进制了,别说做汇编的,估计做CPU的都活不下去了。

有哪几种感觉?身前一亮,还是不可思议?想得更深所以的,是删改还会我人太好这是多此一举,一句sql就能除理的问題图片,搞得没人复杂?

这得从.NET阵营从历史说起。.NET阵营的同学知道三层架构,多半是从PetShop现在始于,这被奉为三层架构的经典,所以有项目甚至是直接克隆技术其架构。在当时,它是三种了不起的进步。那刚刚,还是从ASP向ASP.NET转型的过程,所以有asp项目,sql代码都还是写在html里边的!所以有,UI和DAL的分离,无疑具有明细的示范效应。

三层架构流行起来刚刚,一群人很清楚的知道UI层负责页面交互并调用下一层,也知道DAL层也不和数据库打交道。但BLL层?哪几种才有无“业务逻辑”?有各种各样的解释,但哪几种不删改还会sql做的么?对于绝大多数的应用系统而言,除了对数据库进行“增删改查”以外,我我人太好我想知道还能做些哪几种?更何况,删改还会还有超级强大的存储过程么!

我我人太好,“抽象”、“解耦”、“复用”累似 的说法,都还没人触及根本。最根本的原因 ,还在于一群人的大脑,一群人的大脑不适应于把這個世界抽象成一张一张的表,而更适应于一个 一个 的对象。随着系统日趋复杂,這個问題图片就表现得越明显。

我不才能的话我是为社 么做到的,希望能你才都都还可不可以所以参考。

那为哪几种一群人才能原本做?委托,换言之,把复杂往所以地方推。我记得我反复讲过這個点,架构的一个 重要工作,也不把复杂进行拆分和推诿。拆分估计一群人好理解,但“推诿”是个哪几种意思,推给谁呢?管它呢,我只做我分类的事,所以的,UI推给BLL,BLL推给DAL,DAL推给DBA,DBA推给采购部……

“没人数据库,我都我想知道为社 么现在始于写代码了。”

但微软的步子,不大不小,刚好扯着蛋。

可能是原本的话,恭喜你,你还牢牢的守住了“面向数据库”的阵地。

为了说明,一群人举一个 最简单的例子。

前面写了没人多,很大程度上也不为了這個章做准备。面向对象可能领域驱动,最重要的所以也不要忘记数据库!我花了很长很长的时间,才理解了這個点,从而真正的迈向一个 崭新的天地;而后,我又花了很长很长的时间,才勉强做到這個点;我希望,有一天,这将不再是一个 问題图片,我不才能考虑這個点……

不才能脱离了数据库的束缚,一群人才能自由的翱翔在面向对象的世界里!

我当年,考虑最多的,最不才能接受的,是性能问題图片。

没人,面向对象可能领域驱动应该是为社 么做的呢?

我原本参与过一个 项目,它的数据库社会形态打印出来,得用地图没人大一张纸(我想知道算A几了),密密麻麻的删改还会表,各种线条交错其中,我看着就头皮发麻。部门里边像个宝贝一样把这张表供着,可能公司没人打印也没人复印啊!(我想知道一群人最现在始于是为社 么得来的,估计肯定麻烦)

当然,表的社会形态才才都都还可不可以设计成累似 于继承的样子(类的继承关系也最终会映射成表社会形态),刚刚,在交流沟通中,你如何表明這個抽象关系呢?

你才都都还可不可以假设我的系统删改还会用“关系数据库”存储数据,删改还会mysql,删改还会oracle;我用nosql,我用xml文件存储,行不行?nosql,为社 么用?我想知道啊,我十窍通了九窍。但我想在我还我想知道nosql为社 么用的刚刚,就现在始于构建我的BLL/领域层。为社 你才都都还可不可以只设定哪几只最简单的假设:

所以有,可能你也和我一样,倒回去看我刚刚的博客吧!

“问題图片是我忘不掉啊!”

单纯从系统进程的角度上说,使用ORM,面向对象,还增加了系统的复杂。毕竟多了一道工作,刚刚把对象映射到数据库删改还会一件简单的工作,尤其在等你才能考虑性能问題图片的刚刚。

为哪几种会是原本呢?

可能你一边读一边在想,就会发现,“不对呀,有哪几只表删改还会哪几只类,类图删改还会一样复杂吗?”

原本做,还有所以所以有具体的技术问題图片,一群人后续博客会逐一展开说明。

长期以来,.NET的阵营,在应用级层面,我我人太好是“面向数据库”的。从DataSet、DataGrid、DataSourceBinder累似 的,都才都都还可不可以看出来。即使是Entity Framework,最现在始于也是从数据库的表向.NET的类进行映射。哪几种,都极大的制约了.NET阵营同学面向对象的思维拓展。

总之,发展到今天,随着系统复杂的增加。在系统的分发中,一群人不得不将现实世界首先映射成一个 一个 才都都还可不可以封装、具有继承多态社会形态的对象,刚刚将重心放上去去哪几种对象关系功能的维护上。