如何设计业务逻辑?

 

       软件设计总是很难捉摸,设计虽然不一定决定软件生死,但对软件的开发周期起着非常重要的作用.那怎样的设计能适应软件的变更修改呢?针对我个人而言只能答不知道…因为我在设计的时候只针对现有存在的问题出发,但在后期软件的变更所产生的东西总让人不知所措.虽然设计很难,但有着丰富经验的设计人员总会知道什么时候应该干些什么,而他们的出发点往往不是考虑得非常周全,而是把代码结构变得越简单越好.业务变还是不变我们控制不了,但如何让代码在变更的情况可以方便维护和修改我们还是有一定的能力的.

       详话就不多说了,最近似乎很多人谈三层设计的问题;我来热闹一下,但我谈的没有这么广,紧紧是从业务逻辑设计上来说(细节决定成败).

先看以下代码吧:

public void Create(string username, string email) {

 

        }

 

        public void Create(User user) {

 

        }

其实两个方法完成的功能都是一样的,但两者确有着不同之处.对于我个人而言后者对方法约定变更的风险比较低,因为User类提供信息扩展的提供一些保障.是不是什么情况都这样干呢,显然下面的就没有多大意义了.

        public bool Login(string username, string pwd) {

 

        }

 

        public bool Login(User user) {

 

        }

所以有一点我们可以紧记,程序是死的但人是活的.

以上是逻辑对外的,那逻辑内部呢?同样的方法

    public void Create(string username, string pwd) {

            //insert username,userpwd

            //dal.call(username,userpwd)

        }

 

        public void Create(User user) {

            //DBContext.Add(user)

        }

以上代码两者的差别又在那里呢,这就留给有兴趣的朋友发言讨论了:)

 

还有一个话题:我们如何知道做出来的东西能满足以后的需要呢?如果能做到那唯一的可能就是业务的变化是按我们所假设的方向发展下来,但我们是不是永远都这么好运?如果我们的运气不好那怎样办?这个时候估计只有简单可维护的代码才能把我们从井里救出来…

 

这文章只是提个引子并不是想说这样做设计才是对的,因为设计方法没有最好只有更好.让我们在不停的实践中进步吧.