最近花了几个夜晚帮师妹整了一个企业网站-阿里云开发者社区

开发者社区> 数据库> 正文

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

简介:

背景:

话说年前有个师妹泪眼汪汪,楚楚动情地找我帮她弄个企业网站。

不过那时候,每天都苦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个的肉松饼就很好吃,可是,为啥只买了一个,纳尼?



本文原创发表于博客园,作者为路过秋天,原文链接:http://www.cnblogs.com/cyq1162/p/3573726.html

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章