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

背景：

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

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

 

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

from:http://www.cnblogs.com/cyq1162/p/3573726.html