我写项目的思路和“自然架构”

简介: 我写项目的思路       三层的思路是要把页面(UI、数据显示)、业务逻辑、数据处理(也叫持久化)分离开来处理,思路自然是好的,但是一到了实际应用中,好多人就会遇到一点小小的问题,于是产生了好多的争论。

 

我写项目的思路

 
    三层的思路是要把页面(UI、数据显示)、业务逻辑、数据处理(也叫持久化)分离开来处理,思路自然是好的,但是一到了实际应用中,好多人就会遇到一点小小的问题,于是产生了好多的争论。我觉得一个好的解决方案使用起来应该更容易一些,不应该导致很多人“误入歧途”。所以我觉得三层的分割思路视乎有一点点小问题。

    所以我就想了一个自己的分割方式——业务逻辑与代码分离开来!分离之后就要找到一个契合的点,把分开的两个东东在连系起来,这个契合点就是数据库。(我觉得三层的契合点是实体类)

    我的具体想法就是:
1、 想方设法把业务逻辑(也就是客户提出来的需求)转换成数据库结构。
2、 设计数据库
3、 实现基本的增删改查、统计汇总、报表打印、导出、审批流、个性化设置等功能。

 

    请注意,第三点里面的“实现”是完全不考虑业务逻辑的,也就是说代码写完了之后可以实现各种行业、各种项目的要求(也就是不同的业务逻辑)。以不变应万变的效果。

【示意图】
 

 


    怎么样简单吧,如果把数据库看成中心的话,那么左面是业务逻辑,右面就是程序实现(也就是编码)。如果只看右面的话,那就是和业务逻辑无关的,比如说“添加”,就是添加数据,管他是添加产品信息,还是添加员工信息,还是添加请假信息,还是批准一个出车申请,都是添加数据,那么我是不是可以只考虑如何去添加数据,而不用去考虑添加的到底是员工信息还是请假单呢?于是我就弄出来了一个表单控件,这个控件可以实现添加、修改数据的功能,不管是什么样的业务逻辑(客户的需求),只要是添加、修改数据的、单条记录的,那么就可以使用这个表单控件来实现。这就是我的目的。类似的,如果我要查询,那么我可以使用查询控件(还需要分页控件和现实数据的控件来配合),如果我要向导出到Excel,那也可以使用对应的控件来完成。而我在实现这些控件(编写控件的代码)的时候,根本不用去想业务逻辑。当然控件完成之后要拿到具体的项目里面去验证,然后发现不足的地方再去完善,然后在去检验、完善、检验……。不断进行下去。

    那么具体的实现方式是什么呢?简单的说就是写一大堆的自定义控件,然后把这些控件有机的联系在一起。
 

 


 上次说了,显示数据的控件 + QuickPager + Pager_SQL + DataAccessLibrary + 数据库

就是一个分页的解决方案,再加上查询控件,就可以实现分页和查询功能。

那么同理,表单控件 + Insert、Update的封装 + DataAccessLibrary + 数据库

就是一个单条记录的添加修改的解决方案,再加一个控件就可以实现多条记录的批量修改。

列表和表单结合起来,就是主从表的维护

 

    还有数状结构的功能节点、按钮组、导Excel等控件,这些控件结合起来就可以完成三分之一以上的功能,还有权限管理、个性化设置,一些小的项目就可以横扫了。我还没有做过大项目,可能到了大项目里面,我的这些幼稚的想法就不适合了,但是我有信心,只要我接触了大项目,那么我就会利用我在大项目里面了解、体验、掌握到的经验来完善我的这个想法。因为我就是这么一路走过来的,我想我还没有走到终点吧,呵呵。

 

 自然架构

    自然架构,自然而然,水到渠成。
    信息管理——信息——数据——数据库——关系型数据库

    这就是“自然”,最后为什么是关系型数据库呢?因为他已经好多年了,已经很好很强大了,如果以后OO数据库也可以像关系型数据库这样强大,或者更加的强大,那么最后一个就可以改成OO数据库了。

 

    做了几年的小项目,发现一个问题,对于客户来说什么最重要?数据!我的一个客户是99年成立的,由于行业特殊,有许多数据是要从99年开始一直记录下来,一直到很久很久,于是到现在十年了,至少上千家公司的信息需要录入到新的项目里,以前是保存在Excel或者Access里面的。程序可以换,数据库也可以换,但是数据是不能没有的。

    那我们要做什么呢?就是让客户可以更加方便、快捷、安全的管理数据。我们仅仅是做了一个“工具”,让客户用我们的工具来维护数据。如果企业管理器做得更“傻瓜”一点的话,可能我们就失业了。

    我并不是完全排斥面向对象,我的那些自定义控件,一开始的时候没有用OO的思路来做(因为一开始的时候不会OO),造成了代码很臃肿,难以维护和扩展。后来学习了OO和设计模式,发现用继承、基类、接口,简单抽象工厂、策略模式、模板模式等来做自定义控件确实很方便,结构也比较清楚。这个就是OO的优势。

    什么适合就用什么,不必强求。顺其自然、不做重复劳动,这就是自然架构的宗旨

 

    我知道以数据库为中心,会把范围限制到一个很小的范围,但是这点范围对于我来说也是主够大了,至少两年内是不会感觉小的。一个人的能力有限,能研究出来一点,也是不容易了。 

 ===================================

 

思路还是有点乱,也许是比较激动吧。23号博客园的活动的时候在做现场的演示吧,通过一个简单的实例来具体说一下吧。

欢迎大家多提宝贵意见。谢谢

 

相关文章
|
1月前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
98 2
|
14天前
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
在 Android 开发中,选择合适的架构模式对于构建中大型项目至关重要。常见的架构模式有 MVVM、MVP、MVI、Clean Architecture 和 Flux/Redux。每种模式都有其优缺点和适用场景,例如 MVVM 适用于复杂 UI 状态和频繁更新,而 Clean Architecture 适合大型项目和多平台开发。选择合适的架构应考虑项目需求、团队熟悉度和可维护性。
42 6
|
14天前
|
存储 前端开发 数据可视化
在实际项目中,如何选择使用 Flux 架构或传统的 MVC 架构
在实际项目中选择使用Flux架构或传统MVC架构时,需考虑项目复杂度、团队熟悉度和性能需求。Flux适合大型、高并发应用,MVC则适用于中小型、逻辑简单的项目。
|
23天前
|
前端开发 JavaScript 测试技术
Android适合构建中大型项目的架构模式全面对比
Android适合构建中大型项目的架构模式全面对比
41 2
|
1月前
|
存储 分布式计算 Hadoop
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
Hadoop-33 HBase 初识简介 项目简介 整体架构 HMaster HRegionServer Region
50 2
|
2月前
|
负载均衡 数据库 开发工具
|
25天前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
1月前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
37 0
|
1月前
|
存储 消息中间件 前端开发
.NET常见的几种项目架构模式,你知道几种?
.NET常见的几种项目架构模式,你知道几种?
|
1月前
|
存储 Kubernetes Go
Go语言项目组织架构
Go语言项目组织架构