最近花了几个夜晚帮师妹整了一个企业网站

背景:

话说年前有个师妹泪眼汪汪,楚楚动情最近花了几个夜晚帮师妹整了一个企业网站地找我帮她弄个企业网站。

不过那时候,每天都苦B地闪着:“加班中,相信不用多久升职加薪,当上总经理,出任CEO,迎娶白富美,走上人生巅峰,想想还有点小激动呢”。

所以每夜都懒懒地累到不想动,一直拖延到年后,回到广州才动有了写代码的冲动。

想想毕竟是自家师妹,承诺过的还是要还的,所以打算认真负责的花些时间把它整出来。

 

技术选型:

1:时间考量: 

首先这是一个义务型的网站,所以会考虑时间不能占用太多, 尽量满足基础功能,比较异想天开的功能先忽略。

整体前后沟通和小调整,历长1-2周,实际编码时间,大概24小时内,换算起时间,那也是三个工作日,六个夜晚啊。

2:技术选型:MVC还是WebForm:

A:时间不能占用过多,开发周期不能拉长。

B:个人能临时提供的服务器是2003,只有.NET 2.0,后期可能会转移到对方购买的虚拟主机,所以部署要方便。

C:友好的URL并不是对方在乎的。 

所以综合考虑:WebForm。

像MVC,它的优点是:提供简单友好的URL,对外是一个好的唬头,MVC架构分层思想对新手是一种引导。 

3:数据库选型:MSSQL?Access?Sqlite?

用MSSQL,在这种简单的企业站里,大财小用了。

Access:拥有最弱的并发限制,64K,这个在我以前QBlog系列文章里,把它优化上天了,后来还是离开了。

Sqlite:这个需要最高的信任权限,某些虚拟主机商可能会不支持,而且并发能力和Access差不多一个级别。

 

以我多年的实战经历,这里我选择文本数据库,这里有几个重要思考因素。

1:数据量少:少到可以预估的时间内,文章不会超过1千。

2:占用资源少:目前VPS就1G内存,数据库勉强跑上了sql2000,而且服务器上跑了好几个项目,不适合把这外部的数据放置到自己的项目中。

3:性能要高,抗并发要强:服务器本身配置很低,如果不能抗并发,随便用我提供的分布式压力测试就能搞掉的话,那不坑我自己的服务器。

4:数据的安全性隐私木有要求:这些数据都是可公开的。

综合上面的考虑,MSSQL,虽然能抗并发,这个吃内存,不行,而Access和Sqlite不抗并发,如果选择了它们,意味着我必须考虑到整个缓存机制或生成静态页面机制,这无疑会加长我的开发时间。

 

好在我发现了文本数据库:刚好满足以上的条件,而且文本数据库一直在应用,基本上这个企业站也不在话下,所以最后是用上了CodeFirst方式的文本数据库。

而选择文本数据库,经压力测试,几千上万个并发也不是问题,它天然的内存数据库机制本身就是缓存机制,一次开发,就可以收工了。

实战开发:

1:美工的界面来源: 

首先,她不是美工,我也不会美工,所以,网站需要有参考,好在她给了一款参考网站。

所以,以我的经验,把对方网站那点皮肤弄下来不是什么问题,所以美工的问题看似就解决了,具体看一眼下图,发现是很清秀简洁的:

最近花了几个夜晚帮师妹整了一个企业网站

 2:代码编写:

由于数据库选项是文本数据库,所以基本上就是CodeFirst,定义好业务实体,什么分层,在这里就是浮云:

最近花了几个夜晚帮师妹整了一个企业网站最近花了几个夜晚帮师妹整了一个企业网站最近花了几个夜晚帮师妹整了一个企业网站 

Web.Config就这么一行了:

<connectionStrings>
        <add name="Conn" connectionString="txt path={0}App_Data\db;ts=0"/>
    </connectionStrings>

 

具体运行后产生的数据存储,就在App_Data下的db文件夹下了,一个表就对应一个文本数据了。

另外考虑到文章的字节大,就单独隔离出来一个body文件夹来存放文章,代码也很简单:

public class ArticleBody
    {
        public static void Set(int id, string body)
        {
            string path = AppDomain.CurrentDomain.BaseDirectory + "/App_Data/db/body/" + id + ".body";
            File.WriteAllText(path, body);
        }
        public static string Get(int id)
        {
            string path = AppDomain.CurrentDomain.BaseDirectory + "/App_Data/db/body/" + id + ".body";
            if (File.Exists(path))
            {
                return File.ReadAllText(path);
            }
            return string.Empty;
        }
    }

 

红色那一块是后台,由于偷工减料,所以就不方便公开名称。

3:技术点需要思考的地方:

整个网站,基本上都是简单类似以下的代码:

public partial class ArticleCate : System.Web.UI.UserControl

    {
        protected void Page_Load(object sender, EventArgs e)
        {
            if (!IsPostBack)
            {
                BindList();
            }
        }
        void BindList()
        {
            using (ArticleClass a = new ArticleClass())
            {
                a.Select("order by orderNum asc").Bind(rptList);
            }
        }
    }

不过也有一些需要费点脑的:

3.1:左侧的分类列表,有的点击是直接进入到文章详细,有的点击是直接进入列表界面:

面对这个问题,有着最开始的设计思维:

A:分类名称难道是文章的名称(因为见过的很多基本上都是同名) ?

B:那么要区分显示在列表还是单独的,要在文章里加个字段以区别?

中间的过渡思维:

A:分类名称就是分类名称?

B:分类名称上加个字段,以区别点击是进入指定的某个文章?

最后的决定性思维:

A:分类名称还是分类名称。

B:当分类名称只有一条文章时,地址变为直接指向那篇文章。

 

3.2:文本编辑器的引入:

一开始我是很偷懒的,用一个文本框来发文章,就想了理了。

后来想想不能懒到这程度,毕竟人家是师妹啊,何况我还单身,所以引入文本编辑器升级一下档次也是有必要的。

网上可选的编辑种类很多,FCK,King等网上一搜一个堆,不过我还是思考了一下,如果用上这些:

第一,重,随便一个都几M起步;

第二,图片上传需要自己再折腾,如果运气不好,研究+实现可能会花上一天时间。

第三:我太懒了,我想最多1小时以内就把它给换完。

 

我想到以前QBlog里我写过一个编辑器(改来的),于是直接弄过来,发现原来的代码和QBlog的开发模式有点结合。 

花了几分钟,改了点代码,基本上就能用了,而且重点是文件上传,基本上小改几分钟也适合着用了,省了不少时间。

最近花了几个夜晚帮师妹整了一个企业网站 

 

3.3 产品中心lightBox.js的引入:

这一块就没什么好说的了,就是那种一点图片出来一遮照层,整个背景黑的那种,06年就开始流行的,没想到现在还用的上。 

最近花了几个夜晚帮师妹整了一个企业网站

关于后台:

对于后台,一开始打算用QBlog那种后台方式,或者像EasyUI那种前端,然后搞个CodeSmith批量生成一样,不过一想到这CS不知道放哪了,光找出来就要不少时间,再说它也不支持我的文本数据库。

虽然CodeFirst也支持多种数据库,改个数据库链接就可以转移到其它数据库,然后再借CS去生成,不过感觉这转来转去的麻烦。 

于是,心一横,就那几个表,也就几个界面,还不如手工来的快,于是一个木有样式,惨不忍睹的界面,只有最简单的增删改查逻辑的后台就出来了。

由于后台界面这一块太丑,就不截图了,免的亮瞎了大伙的眼睛。

 

网站预览(已失效):http://paileju.com
至于源码,想要来学习的也可以Q我,随便给。

总结:

到此,基本上就算完工了,搞完之后,收到了师妹寄来的零食,也算是一种回报了,虽然大部分零售是辣的不合我口味,不过还是有不少零售味道还是不错的,像那个1块钱1个的肉松饼就很好吃,可是,为啥只买了一个,纳尼?

 

新的一年,要重新卖身了,打算漂泊,城市不限,欢迎大伙推荐买主,谢谢。

 

相关文章

暂无评论

暂无评论...