数据库设计与Linq增强使用

最近对数据库的设计有些想法,貌似一般数据都有些通用字段

public interface IData
    {
        /// 
        /// 数据ID标识
        /// 
        decimal ID { get; set; }
        /// 
        /// 更新时间
        /// 
        DateTime UpdateTime { get; set; }
        /// 
        /// 数据状态
        /// 
        int State { get; set; }
        /// 
        /// 创建时间
        /// 
        DateTime CreateTime { get; set; }
    }

其中ID是自增长主键(SQL,Oracle环境可以是Sequence生成的ID)

UpdateTime是最后一次更新时间

CreateTime是创建时间

State是数据状态(本来的设想里没有,看了这个文章觉得状态字段实在太需要了。。)

类型如下:

数据库就这样了。。有什么用呢~?继续看。。

在这个的基础上,可以抽象出一个 IData 接口:

IData 接口

public interface IData

    {

        /// 

        /// 数据ID标识

        /// 

        decimal ID { get; set; }

        /// 

        /// 更新时间

        /// 

        DateTime UpdateTime { get; set; }

        /// 

        /// 数据状态

        /// 

        int State { get; set; }

        /// 

        /// 创建时间

        /// 

        DateTime CreateTime { get; set; }

    }

因为数据库的表字段跟IData属性成员是一致的,直接对Linq生成的实体类进行接口签名:

IData 接口签名

签名放在

一般没人用的Linq设计器cs文件里面了。。好处是方便跟着那个大坨的Linq文件走。。

这个文件右键dbml文件 -> 查看代码就出现了,默认是不出现的(因为很惹人讨厌,之前不小心弄出来了我都会把它删掉。。现在用上了。。)

当然了,上面的借口签名不是一个一个写出来的,直接CodeSmith很简单的就出来了

接下来,针对IData进行扩展:

数据对象扩展

    /// 

    /// 数据对象扩展

    /// 

    public static class DataExtension

    {

        /// 

        /// 保存或更新

        /// 

        /// 要保存或更
新的数据

        /// 操作结果

        public static bool SaveOrUpdate(this IData data)

        {

            bool success = false;

            CIIDesignerDataContext db = new CIIDesignerDataContext();

            // todo: save or update 

            if (data.ID < 1)

            {

                // todo: save

                data.CreateTime = DateTime.Now;

                data.UpdateTime = DateTime.Now;

                db.GetTable(data.GetType()).InsertOnSubmit(data);

                

            }

            else

            {

                // todo: update

                data.UpdateTime = DateTime.Now;

                db.GetTable(data.GetType()).Attach(data);

                db.SubmitChanges();

            }

try

            {

                db.SubmitChanges();

                success = true;

            }

            catch

            {

                success = false;

            }

            return success;

        }

/// 

        /// 删除数据

        /// 

        /// 要删除的数据

        /// 操作结果

        public static bool Delete(this IData data)

        {

            bool success = false;

            CIIDesignerDataContext db = new CIIDesignerDataContext();

            db.GetTable(data.GetType()).Attach(data);

            db.GetTable(data.GetType()).DeleteOnSubmit(data);

            try

            {

                db.SubmitChanges();

                success = true;

            }

            catch (Exception)

            {

                success = false;

            }

            return success;

        }

    }

这样下来每个实体类可以直接增删改:(不知道这样用处大不大。。)

好了,现在我们的Linq实体类可以直接增删改,不用关心Linq的DataContext了,充血充的更厉害了……

但是查询的时候还是没办法彻底摆脱Linq的DataContext,再来~

不知道命名,就赶新潮也叫Repository(其实还是DataContext的范畴)

数据存储池

/// 

    /// 数据存储池

    /// 

    /// 

    public class Repository<T> where T : class, IData

    {

        CIIDesignerDataContext db = new CIIDesignerDataContext();

/// 

        /// 创建数据对象

        /// 

        /// 

        public T Create()

        {

            return (T)Activator.CreateInstance(typeof(T));            

        }

/// 

        /// 根据主键
获取数据

        /// 

        /// 主键ID

        /// 

        public T FindByID(decimal ID)

        {

            return db.GetTable<T>().FirstOrDefault(c => c.ID == ID);

        }

/// 

        /// 获取数据Query

        /// 

        /// 

        public IQueryable<T> GetQuery()

        {

            return db.GetTable<T>().AsQueryable();

        }

///

时间: 2024-10-25 18:30:24

数据库设计与Linq增强使用的相关文章

艾伟_转载:数据库设计与Linq增强使用

最近对数据库的设计有些想法,貌似一般数据都有些通用字段     public interface IData     {         ///          /// 数据ID标识         ///         decimal ID { get; set; }         ///          /// 更新时间         ///         DateTime UpdateTime { get; set; }         ///          /// 数据状

数据库设计方法、规范与技巧

规范|技巧|设计|数据|数据库|数据库设计 数据库设计方法.规范与技巧(推荐)   一.数据库设计过程数据库技术是信息资源管理最有效的手段.数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求.数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点.独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述.在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系

数据库设计方法、规范与技巧(推荐)

规范|技巧|设计|数据|数据库|数据库设计 数据库设计方法.规范与技巧(推荐)   一.数据库设计过程数据库技术是信息资源管理最有效的手段.数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求.数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点.独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述.在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系

我对关系型数据库设计范式的理解

我对关系型数据库设计范式的理解 所谓范式,是关系型数据库关系模式规范化的标准,从规范化的宽松到严格,分别为不同的范式,通常使用的有第一范式.第二范式.第三范式及BC范式等.范式是建立在函数依赖基础上的. 函数依赖 定义:设有关系模式R(U),X和Y是属性集U的子集,函数依赖是形为X→Y的一个命题,对任意R中两个元组t和s,都有t[X]=s[X]蕴t[Y]=s[Y],那么FD X→Y在关系模式R(U)中成立.X→Y读作'X函数决定Y',或'Y函数依赖于X'. 通俗的讲,如果一个表中某一个字段Y的值

大型MIS软件的开发必须重视数据库设计

80年代初以来,国内许多计算机专家先后深入一些大型企业,力图开发出理想的大型MIS.实践证明,开发出的大型MIS,多数不很理想.原因何在?据作者一孔之见,其中一条重要的原因,就是在开发过程中对MIS的数据库设计重视不够,没有把它当作一件头等大事来处理.一个大型MIS,如果它的数据库设计出了问题,就是出了大问题,或者说从根本上出了问题.这样的MIS,不会成功,只会失败.既然如此,应该怎样来解决它呢? 一.MIS的基础是数据库 MIS系统包括硬件和软件两部分.MIS的软件,是由文档加程序组成的.它的

100TB级, 日增量1TB(100亿), OLTP OLAP混合场景数据库设计方向

标签 PostgreSQL , LLVM , JIT , 并行 , 列存储 , GPU , 向量计算 , HLL , 流计算 , OSS对象存储结合   背景 总量100TB,日增量1TB(日增约100亿记录)左右.这样的体量应该可以覆盖目前绝大多数企业的数据库体量. 提到100TB级别,OLTP和OLAP的混合场景,大家可能会想到Oracle的一体机extradata,没错Oracle在这方面做得确实是非常棒的,但是价格也是很漂亮的. Oracle主要通过几个方面来提升它在这个级别的性能: 共

云端海量任务调度系统数据库设计 - 阿里云RDS PostgreSQL案例

标签 PostgreSQL , 任务调度系统 , 数据库设计 , schemaless 背景 任务调度系统中的任务状态管理,通常会用到数据库来存储任务调度的过程状态,控制任务的锁等. <advisory lock 实现高并发非堵塞式 业务锁> 如果是小量任务,是挺好实现的,但是每小时处理几十亿或者几亿的任务,如何设计这样的任务状态管理数据库呢? 挑战 对于一个面向多个用户的任务调度平台(例如云端的任务调度平台,将面向所有租户使用). 较大的挑战是任务数据的写入(海量),另一个是任务状态的更新(

MySQL 第七篇:数据库设计、视图与触发器

我把MySQL的内容整理成9篇博客,学完这9篇博客虽不能说能成为大神,但是应付一般中小企业的开发已经足够了,有疑问或建议的欢迎留言讨论. 数据库设计 为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某一种设计要求的总结.要想设计一个结构合理的关系型数据库,必须满足一定的范式.现在对数据库设计范式要求不高,了解即可. 一.第一范式:确保每列的原子性. 如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足

数据库设计技巧奉送了_数据库其它

1. 设计数据库之前(需求分析阶段)     1) 理解客户需求,询问用户如何看待未来需求变化.让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中.     2) 了解企业业务可以在以后的开发阶段节约大量的时间.     3) 重视输入输出.     在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表.查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段.     举例:假如客户需要一个报表按照邮政编码排序.分段和求和,你要保证其中