两种底层数据层操作时的架构方式,你喜欢那种?

简介:
第一种,效率较高,也是很多开源项目用的方法,使用了贬型
第二种,比较基础,安全性比较高,讲究面向接口的编程,我所以实体对象都继承自统一的接口
 
    #region 数据底层操作架构一
    /// <summary>
    /// 用户实体
    /// </summary>
    public class User
    {
        public string UserName { get; set; }
        public int Age { get; set; }
    }
 
    public class UserRepository : IRepository<User>
    {
 
        #region IRepository<User> Members
 
        public User Get(object id)
        {
            User user = new User { };
            return user;
        }
 
        public IQueryable<User> GetList()
        {
            throw new NotImplementedException();
        }
 
        #endregion
    }
 
    /// <summary>
    /// 数据操作统一接口,它提供一个贬型作为参数,但要求贬型必须是类
    /// </summary>
    /// <typeparam name="T"></typeparam>
    public interface IRepository<T> where T : class
    {
        /// <summary>
        /// 获取实体
        /// </summary>
        /// <param name="id">主键</param>
        /// <returns></returns>
        T Get(object id);
        /// <summary>
        /// 得到列表
        /// </summary>
        /// <returns></returns>
        IQueryable<T> GetList();
    }
    #endregion
 
    #region 数据底层操作架构二
    class User2 : IDataEntity
    {
        public string UserName { get; set; }
        public int Age { get; set; }
    }
    /// <summary>
    /// 数据实体统一接口
    /// </summary>
    public interface IDataEntity
    {
    }
    /// <summary>
    /// 数据操作统一接口
    /// </summary>
    public interface IRepository2
    {
        /// <summary>
        /// 获取实体
        /// </summary>
        /// <param name="id">主键</param>
        /// <returns></returns>
        IDataEntity Get(object id);
        /// <summary>
        /// 得到列表
        /// </summary>
        /// <returns></returns>
        IQueryable<IDataEntity> GetList();
    }
    public class User2Repository : IRepository2
    {
 
        #region IRepository2 Members
 
        public IDataEntity Get(object id)
        {
            throw new NotImplementedException();
        }
 
        public IQueryable<IDataEntity> GetList()
        {
            throw new NotImplementedException();
        }
 
        #endregion
    }
    #endregion
 
目录
相关文章
|
5月前
|
存储 BI Shell
Doris基础-架构、数据模型、数据划分
Apache Doris 是一款高性能、实时分析型数据库,基于MPP架构,支持高并发查询与复杂分析。其前身是百度的Palo项目,现为Apache顶级项目。Doris适用于报表分析、数据仓库构建、日志检索等场景,具备存算一体与存算分离两种架构,灵活适应不同业务需求。它提供主键、明细和聚合三种数据模型,便于高效处理更新、存储与统计汇总操作,广泛应用于大数据分析领域。
542 2
|
5月前
|
SQL 缓存 前端开发
如何开发进销存系统中的基础数据板块?(附架构图+流程图+代码参考)
进销存系统是企业管理采购、销售与库存的核心工具,能有效提升运营效率。其中,“基础数据板块”作为系统基石,决定了后续业务的准确性与扩展性。本文详解产品与仓库模块的设计实现,涵盖功能概述、表结构设计、前后端代码示例及数据流架构,助力企业构建高效稳定的数字化管理体系。
|
4月前
|
数据采集 缓存 前端开发
如何开发门店业绩上报管理系统中的商品数据板块?(附架构图+流程图+代码参考)
本文深入讲解门店业绩上报系统中商品数据板块的设计与实现,涵盖商品类别、信息、档案等内容,详细阐述技术架构、业务流程、数据库设计及开发技巧,并提供完整代码示例,助力企业构建稳定、可扩展的商品数据系统。
|
3月前
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
168 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
3月前
|
JSON 供应链 监控
1688商品详情API技术深度解析:从接口架构到数据融合实战
1688商品详情API(item_get接口)可通过商品ID获取标题、价格、库存、SKU等核心数据,适用于价格监控、供应链管理等场景。支持JSON格式返回,需企业认证。Python示例展示如何调用接口获取商品信息。
|
4月前
|
数据采集 监控 数据可视化
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
本案例讲述了在豆瓣电影数据采集过程中,面对数据量激增和限制机制带来的挑战,如何通过引入爬虫代理、分布式架构与异步IO等技术手段,实现采集系统的优化与扩展,最终支撑起百万级请求的稳定抓取。
167 0
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
|
4月前
|
SQL 数据采集 数据处理
终于有人把数据架构讲清楚了!
本文深入浅出地解析了数据架构的核心逻辑,涵盖其定义、作用、设计方法及常见误区,助力读者构建贴合业务的数据架构。
|
5月前
|
数据采集 存储 分布式计算
一文读懂数据中台架构,高效构建企业数据价值
在数字化时代,企业面临数据分散、难以统一管理的问题。数据中台架构通过整合、清洗和管理数据,打破信息孤岛,提升决策效率。本文详解其核心组成、搭建步骤及常见挑战,助力企业高效用数。
1749 24
|
4月前
|
缓存 前端开发 BI
如何开发门店业绩上报管理系统中的门店数据板块?(附架构图+流程图+代码参考)
门店业绩上报管理是将门店营业、动销、人效等数据按标准化流程上报至企业中台或BI系统,用于考核、分析和决策。其核心在于构建“数据底座”,涵盖门店信息管理、数据采集、校验、汇总与对接。实现时需解决数据脏、上报慢、分析无据等问题。本文详解了实现路径,包括系统架构、数据模型、业务流程、开发要点、三大代码块(数据库、后端、前端)及FAQ,助你构建高效门店数据管理体系。
|
8月前
|
存储 运维 Serverless
千万级数据秒级响应!碧桂园基于 EMR Serverless StarRocks 升级存算分离架构实践
碧桂园服务通过引入 EMR Serverless StarRocks 存算分离架构,解决了海量数据处理中的资源利用率低、并发能力不足等问题,显著降低了硬件和运维成本。实时查询性能提升8倍,查询出错率减少30倍,集群数据 SLA 达99.99%。此次技术升级不仅优化了用户体验,还结合AI打造了“一看”和“—问”智能场景助力精准决策与风险预测。
710 69

热门文章

最新文章