Tag: 设计

如何在严格分层的架构中拆分层并促进模块化而不会造成不必要的冗余?

我已经收到了开始为我公司的代码库建立新架构的基础。 这项倡议的推动力是: 我们的代码库已有十多年的历史,并且在我们尝试扩展时最终在接缝处打破。 如果你想称它们为顶层的“层”,那就是经典的ASP和.NET。 我们的数据库充满了一堆不圣洁的存储过程,其中包含数千行业务逻辑和validation。 以前的开发人员创建了“聪明”的解决方案,这些解决方案是不可扩展的,不可重用的,并且具有非常明显的反模式; 这些需要在短时间内弃用。 当我致力于初始设计时,我一直非常重视MS模式和实践架构指南 ,但在我做任何事情之前,我仍然有一些挥之不去的问题。 在我开始讨论问题之前,这是我到目前为止的架构: (高水平) (业务和数据层深入) 这些图基本上显示了我打算如何将每个层分成多个组件。 所以在这个候选架构中,我们有11个组件,不包括最顶层。 这是故障,每个组件的描述: Company.Project.Common.OperationalManagement :包含实现exception处理策略,日志记录,性能计数器,配置和跟踪的组件。 Company.Project.Common.Security :包含执行身份validation,授权和validation的组件。 Company.Project.Common.Communication :包含可用于与其他服务和应用程序(基本上是一堆可重用的WCF客户端)通信的组件。 Company.Project.Business.Interfaces :包含用于从高级层与业务层交互的接口和抽象类。 Company.Project.Business.Workflows :包含与业务工作流的创建和维护相关的组件和逻辑。 Company.Project.Business.Components :包含封装业务规则和validation的组件。 Company.Project.Business.Entities :包含代表高级业务实体的数据对象。 其中一些可能是唯一的,一些可能是由来自数据层的更精细数据实体形成的复合物。 Company.Project.Data.Interfaces :包含用于与存储库样式中的数据访问层交互的接口和抽象类。 Company.Project.Data.ServiceGateways :包含用于调用和从外部系统获取数据的服务客户端和组件。 Company.Project.Data.Components :包含用于与数据库通信的组件。 Company.Project.Data.Entities :包含更多细粒度的实体,这些实体表示低级别的业务数据,适合以事务方式持久保存到数据库或其他数据源。 我的意图是这应该是一个严格的分层设计(一个层可能只与它下面的层进行通信),并且层的模块化分解应该促进高内聚和松散耦合。 但我仍有一些担忧。 以下是我的问题,我认为这些问题足够客观,因此它们适用于此… 我的每个模块及其各自的程序集的命名约定是否遵循标准约定,或者我应该采用不同的方式进行此操作? 将业务和数据层分成多个程序集是否有益? 在自己的程序集中为每个层设置接口和抽象类是否有益? 最重要的是 – 为业务层和数据层都有一个“实体”程序集是否有益? 我关注的是,如果在数据访问组件中包含将由LINQ to SQL生成的类,则给定实体将在代码库中的三个不同位置表示。 显然,像AutoMapper这样的工具可能会有所帮助,但我仍然不是100%。 我让它们像这样分开的原因是A – 强制执行严格的分层架构和B – […]

使用.NET进行multithreading文件处理

有一个包含1000个小文本文件的文件夹。 我的目标是解析和处理所有这些文件,同时将更多文件填充到文件夹中。 我的目的是multithreading这个操作,因为单线程原型花了六分钟来处理1000个文件。 我喜欢读写器线程如下。 当读者线程正在读取文件时,我想让编写器线程来处理它们。 一旦阅读器开始阅读文件,我想将其标记为正在处理,例如通过重命名。 读完后,将其重命名为已完成。 我如何处理这样的multithreading应用程序? 使用分布式哈希表或队列更好吗? 我使用哪种数据结构可以避免锁定? 这个方案有更好的方法吗?

如何为我的坐标系获得“更薄”的图形?

接下来,我有一堆坐标,我将它们作为坐标系统绘制在位图图像上。 现在,我想摆脱所有的噪音,并过滤坐标,以提供“更清晰”或“更清洁”的路径和“更少”或“更好”的数据。 为了解释更多,我需要展示我的精彩 绘画技巧,如下所示: 当前: 期望: 注意: 我需要删除坐标 我可能需要添加坐标 在某些情况下,我可能需要忽略最短邻居 我唯一能想到的是使用最短路径算法,如A *和Dijkstra 。 并在某种数据结构中填充数据以包含每个节点的邻居和成本,然后执行该算法。 我不想开始一些可能错误或浪费的事情。 如果可能的话,我很想看到伪代码如何解决这样的问题 ? PS我目前正在使用Wpf C#,但我愿意使用C#或C ++来完成任何任务。 谢谢

If语句太多了?

我有一个类使用EPPlus从电子表格中读取文本。 它工作正常,它完全符合我的要求,但我觉得我这样做是不好的做法,但对于我的生活,我不能找出一个不太硬编码的替代方案,并且使用较少的if语句。 该类包含常量,如 private static string configUserName; private static string configPassword; private static string configUrl; private static string configDatabase; //etc 其中大约有40个。 该类循环遍历一个电子表格,读取所有值,检查它是什么值: int i = 1; object isRow = currentWorksheet.Cells[i, 1].Value; while (isRow != null) { if (isRow.ToString().Trim().Equals(“change_bank_details_policy”)) { if (currentWorksheet.Cells[i, 2].Value != null) { change_bank_details_policy =c currentWorksheet.Cells[i,2].Value.ToString().Trim(); } } else if //etc 40 more […]

为什么匿名类型不能传递给方法?

什么是倾向于不从方法返回匿名类型的设计决策?

什么时候应该封装generics类型?

我见过很多人建议你应该用类更接近你的域封装generics类型,例如Steve和Nat在增长面向对象软件中的建议,在测试的指导下 : 我们的经验法则是我们试图用generics来限制传递类型[…]。 特别是当应用于集合时,我们将其视为一种复制forms。 这是一个暗示,应该将一个域概念提取到一个类型中。 一般来说,什么时候做这样的事情是个好主意.. class PersonList : List ..而不是直接使用List ?

.NET中的错误通信和恢复方法

我试图在我的C#代码中进行错误通信和恢复,而不使用exception。 举个例子,假设有一个Func A,它可以被Func B或Func C或其他函数调用。 必须设计Func A以保持重用。 (此应用程序有一个不断发展的库,新function将在一段时间内不断添加) 如果Func A无法执行它应该执行的操作,则返回int,其中任何非零值表示失败。 我也想传达失败的原因。 调用者函数可以多种方式使用此信息: 它可以向用户显示错误消息, 它可能会显示与其上下文更相关的错误消息 它本身可能返回一个int值,表示无法进一步激活调用者函数。 它可能会尝试使用一些智能算法从错误中恢复。 假设其他函数所依赖的任何函数可能需要将多个事物传递给其调用函数以采取适当的操作,包括状态代码,错误消息和指示数据状态的其他变量。 将所有内容作为分隔字符串返回可能不允许调用者函数在不解析字符串的情况下检索信息(这将导致其自身的问题,并且不建议使用)。 唯一的另一种方法是返回包含所有必需信息的成员变量的对象。 这可能会导致太多“状态”对象,因为每个函数都需要具有其状态对象。 我想了解如何以最优雅的方式设计此要求。 请注意,在编码时,Func A可能不知道调用函数是否具有从错误中恢复的智能,因此我不想抛出exception。 此外,我想看看这样的设计是否可行(并且同时优雅)而不使用exception。 如果唯一的方法是使用每个函数的数据对象进行通信,那么它是专业库的编写方式。 可以有通用数据对象吗? 注意将来可能会添加新function,这些function可能具有不同的状态变量,或者支持有关其错误的信息。 还要注意,由于函数的返回值是一个“状态”对象,因此它应该返回的实际数据可能需要作为ref或out参数传递。 这有设计模式吗? 在发布此问题之前,我已阅读以下文章: http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx 当没有抛出exception时,try / catch块是否会损害性能? error handling没有例外 我还阅读了许多其他文章,建议不要使用代码流控制的exception,以及可恢复的错误。 此外,抛出exception有其自身的成本。 此外,如果调用函数想要从每个被调用函数抛出的exception中恢复,它将必须用try catch块包围每个函数调用,因为通用try catch块将不允许从下一行“继续”错误行。 编辑: 一些具体问题:我需要编写一个同步2个不同数据库的应用程序:一个是专有数据库,另一个是SQL Server数据库。 我想在一个单独的层中封装可重用的函数。 function如下:专有应用程序可以有许多数据库。 需要将来自每个数据库的一些信息推送到单个公共SQL Server数据库。 只有当应用程序的GUI处于打开状态并且只能通过XML读取时,才能读取专有应用程序的数据库。 算法是这样的: 阅读Proprietory应用程序中的开放数据库列表 对于每个数据库,启动同步过程。 检查此数据库中当前登录的用户是否具有“同步权限”。 (注意:可以使用不同的用户ID打开每个数据库)。 从此数据库中读取数据。 […]

设计以避免派生类中的类型转换?

public interface IBasePresenter { } public interface IJobViewPresenter : IBasePresenter { } public interface IActivityViewPresenter : IBasePresenter { } public class BaseView { public IBasePresenter Presenter { get; set; } } public class JobView : BaseView { public IJobViewPresenter JobViewPresenter { get { this.Presenter as IJobViewPresenter;} } } public class ActivityView : BaseView { public […]

在数据库中保存类的最佳方法?

在数据库中表示“类型”的好方法是什么? 我有一个基类Action ,它由许多子类inheritance。 Action具有Id , Name等成员,它们对应于名为action的数据库中的表中的等效列。 所以action表看起来像这样: id | name | type type列表示它是什么动作。 在我的代码中,它们对应于从父Action派生的子类。 现在如何将类的类型保存到数据库中的类型字段 ? db中的type列可以是任何数据类型。 选项: 保存action.GetType().ToString()作为db中的字符串。 通过使用reflection将类型的字符串表示转换为其原始类型,从db获取操作类型。 但如果将来类名改变,这将是有问题的。 创建一个枚举来表示每个子类并通过TypeAttribute装饰,例如: public abstract class Action { public enum Kind { [Type(typeof(ControlAction))] ControlAction = 1, [Type(typeof(UpdateAction))] UpdateAction = 2, etc } public abstract Kind ActionType { get; } } public class ControlAction : Action { […]

在IDisposable类层次结构中正确处理ObjectDisposedException

正确实现IDisposable时,大多数实现(包括框架指南)都建议包含一个private bool disposed; 成员为了安全地允许多次调用Dispose() , Dispose(bool)以及在适当时抛出ObjectDisposedException 。 这适用于单个类。 但是,当您从可支配资源中inheritance子类,并且子类包含其自己的本机资源和独特方法时,事情会变得有点棘手。 大多数示例都展示了如何正确地重写Dipose(bool disposing) ,但不要超越它来处理ObjectDisposedException 。 在这种情况下,我有两个问题。 第一: 子类和基类都需要能够跟踪处置状态。 我知道有几个主要选项 – 1)声明私人布尔处置; 在这两个class级。 每个类跟踪它自己的this.disposed,并根据需要抛出。 2)使用protected bool Disposed {get; 私人集; 而不是一个字段。 这会让子类检查处理状态。 3)提供一些受保护的辅助方法来检查处理状态,如果对象被处理则通过reflection拉动当前类型名称来抛出。 我看到每个选项的优点是: 1)这“气味”给我,因为它包含重复的布尔值,但似乎工作正常。 我经常在子类化其他代码时使用它。 2)这取出了重复的布尔值,但不是设计指南书的编写方式等。这是我通常使用的,因为它使状态保持单点。 3)这对我来说似乎是最干净的选择,但没有出现在标准指南中。 对于一种方法而言,它可能比该类用户的其他方式要少一些。 在某些方面,我尝试过使用这三种方法。 我想知道这三种方法的优点和缺点,以及任何其他想法,以更清洁,更好的方式来处理这个问题。 你在处理这个问题时会做出什么选择?为什么? 第二: 抛出ObjectDisposedException ,您对name参数使用了什么? 我知道“典型”的方法调用是: throw new ObjectDisposedException(GetType().FullName); Microsoft员工在此页面上发表评论,建议实施具体类的全名是适当的用法。 在上面的第三个选项中,这将是唯一有意义的选择。 但是,如果类实现了throw本身,则可能会返回定义所调用方法的类的名称。 (即:基类可以返回基类的名称,而不是具体的子类) 我认为这不是一个好主意 – 但我在其他人编写的代码上遇到了这个问题。 使用实现方法的类的名称返回是有优点还是缺点?