Tag: 架构

分层体系结构中的exception处理

我们正在重构（并且当然是重新设计）我们的分层设计服务。 我们有服务操作层（BLL），网络抽象层 – >（处理网络代理），数据抽象层。 但我们对我们的exception处理策略感到有些困惑。 我们不希望从BLL向外界透露太多信息。 （从其他层到bll都很好） 我们不想用try catch堆栈来混淆代码 我们不希望在catch块中混淆exception处理代码（如日志记录，电子邮件等） 有人可以发布一些代码示例或文献指针，我们可以用它来设计我们简单的exception处理框架吗？

服务器推送与客户端拉取代理服务器拓扑

我需要创建一个包含2个组件的系统： 处理和存储数据的单个服务器。 它还定期向代理发送更新 安装在远程端点的多个代理程序。 这些数据收集（通常但不总是）长时间运行的数据，这些数据需要到达服务器 我正在使用C＃.NET，理想情况下我想使用符合标准的通信方法（即可以与Java合作的方法，因为我们将来也可能使用Java代理）。 有没有Web服务的替代品？ 我有什么选择？ 我看到它的方式我有3个选项使用Web服务，并做了以下观察： 客户拉 代理不需要开放端口，因为它像客户端一样 需要轮询服务器以获取更新 服务器推送 在代理程序中打开端口，因为它充当服务器 服务器必须轮询代理以获取结果 混合动力 在代理程序中打开端口，因为它的作用类似于客户端和服务器 没有民意调查; 服务器在需要时推送更新，客户端在可用时发送结果 “混合”（代理商既是客户端又是服务器）似乎是明显的选择 – 但这个应用程序通常会安装在企业和政府环境中，我担心他们可能会遇到在代理商处打开端口的问题。我是住在这上面太多了？ 我错过了其他任何利弊吗？

从架构上讲，我应该如何用更易于管理的东西替换一个非常大的switch语句？

编辑1：忘记添加嵌套属性曲线球。 更新：我选择了@ mtazva的答案，因为这是我特定案例的首选解决方案。 回想起来，我用一个非常具体的例子问了一个普遍的问题，我认为这最终会使每个人（或者也许只是我）混淆这个问题究竟是什么。 我相信一般性问题也得到了回答（参见战略模式答案和链接）。 感谢大家！ 很大的开关语句显然有气味 ，我已经看到了一些关于如何使用映射到函数的字典来实现这一点的链接。 但我想知道是否有更好的（或更聪明的方法）来做到这一点？ 在某种程度上，这是一个我总是在脑后滚动的问题，但从来没有真正有一个很好的解决方案。 这个问题源于我之前提到的另一个问题： 如何使用C＃在.Net中的类型对象列表中选择对象属性的所有值 这是我正在使用的示例类（来自外部源）： public class NestedGameInfoObject { public string NestedName { get; set; } public int NestedIntValue { get; set; } public decimal NestedDecimalValue { get; set; } } public class GameInfo { public int UserId { get; set; } public int MatchesWon { get; […]

从另一个命令Handle（）方法中调用命令

您好我正在使用Simple Injector DI库并且已经关注了一些关于围绕命令模式设计的架构模型的非常有趣的材料： 同时……在我的架构的命令端 同时……在我的架构的查询方面 容器将管理UnitOfWork的生命周期，我使用命令来执行数据库的特定function。 我的问题是，如果我有一个命令，例如AddNewCustomerCommand ，它反过来又对另一个服务执行另一个调用（即发送文本消息），从设计的角度来看这是可以接受的，还是应该在更高的层次上完成，如果是的话怎么做到最好？ 示例代码如下： public class AddNewBusinessUnitHandler : ICommandHandler { private IUnitOfWork uow; private ICommandHandler otherHandler; AddNewBusinessUnitHandler(IUnitOfWork uow, ICommandHandler otherHandler) { this.uow = uow; this.otherHandler = otherHandler; } public void Handle(AddBusinessUnitCommand command) { var businessUnit = new BusinessUnit() { Name = command.BusinessUnitName, Address = command.BusinessUnitAddress }; var otherCommand = new […]

具有行为和ORM的丰富域模型

在观看了Jimmy Bogard（ http://ndcoslo.oktaset.com/Agenda ）的NDC12演示文稿“Crafting Wicked Domain Models”之后，我正在徘徊如何坚持这种域模型。 这是演示文稿中的示例类： public class Member { List _offers; public Member(string firstName, string lastName) { FirstName = firstName; LastName = lastName; _offers = new List(); } public string FirstName { get; set; } public string LastName { get; set; } public IEnumerable AssignedOffers { get { return _offers; } } […]

MVVM：如何处理嵌套的ViewModel之间的交互？

我一直在尝试经常提到的MVVM模式，在某些情况下我很难定义明确的边界。 在我的应用程序中，我有一个对话框，允许我创建到Controller的连接。 对话框有一个ViewModel类，这个类很简单。 但是，该对话框还包含一个附加控件（由ContentTemplateSelector选择），该控件根据所连接的Controller的特定类型而有所不同。 此控件具有自己的ViewModel。 我遇到的问题是，当我按OK键关闭对话框时，我需要实际创建请求的连接，这需要在内部Controller特定的ViewModel类中捕获的信息。 简单地让所有特定于Controller的ViewModel类实现构建连接的公共接口是很诱人的，但是内部ViewModel是否应该真正负责这种构造？ 我的一般问题是：ViewModel应该如何与彼此交互，是否有任何普遍接受的设计模式，特别是当’父’VM需要来自’子’VM的帮助以便知道该怎么做？ 编辑： 我确实想出了一个比我原先想象的更清洁的设计，但我仍然不确定这是否是“正确”的方式。 我有一些后端服务，允许ContentTemplateSelector查看Controller实例并伪神奇地找到要为连接构建器显示的控件。 让我烦恼的是我的顶级ViewModel必须查看生成的控件的DataContext并将其转换为适当的界面，这似乎是个坏主意（为什么View的DataContext与创建有关？连接？） 我结束了这样的事情（简化）： public interface IController { IControllerConnectionBuilder CreateConnectionBuilder(); } public interface IControllerConnectionBuilder { ControllerConnection BuildConnection(); } 我有我的内部ViewModel类实现IControllerConnectionBuilder ，Controller返回内部ViewModel。 然后，顶级ViewModel可视化此IControllerConnectionBuilder （通过伪魔法机制）。 它仍然困扰我一点，这是我的内部ViewModel执行构建，但至少现在我的顶级ViewModel不必知道脏细节（它甚至不知道或不关心可视化控件正在使用视图模型）。 如果有办法进一步清理它，我欢迎其他想法。 我仍然不清楚ViewModel有多少责任“好”。

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

我已经收到了开始为我公司的代码库建立新架构的基础。 这项倡议的推动力是： 我们的代码库已有十多年的历史，并且在我们尝试扩展时最终在接缝处打破。 如果你想称它们为顶层的“层”，那就是经典的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应用程序？ 使用分布式哈希表或队列更好吗？ 我使用哪种数据结构可以避免锁定？ 这个方案有更好的方法吗？

我是否应该像在DAL项目中的poco类一样在BLL项目类中创建，如果我想从数据库中显示数据，则将其返回到UI项目？

我有一个架构问题。 我有DOL项目与poco类（数据库中的等价表），BLL项目和UI项目。 UI项目参考了BLL项目，BLL项目参考了DAL项目。 我想在UI项目数据中显示例如来自数据库的表Product。 我应该在BLL项目类中创建像DAL项目中的poco类一样，并将其返回到UI项目并显示它吗？ 所以这是DAL中的poco类（数据库中的等效表）： public class Product { public int ID {get; set; } public string Name {get; set; } public String Address {get; set; } } 在BLL中，我创建了与上面的poco类相同的业务对象： public class ProductBO { public int ID { get; set; } public string Name { get; set; } public String Address { get; set; } […]

一个安全地提供公共API（只读）和私有API（读写）的对象

这是一个架构问题。 程序员经常遇到这种封装问题，但我还没有看到一个完整而干净的解决方案。 相关问题： 当一个非只读类已经到位时，只读类设计 控制对字段的读/写访问 通常，在OOP范例中，对象将其数据存储在字段中。 该类自己的方法可以完全访问其字段。 当您需要返回值时，您只需返回数据的副本，以便外部代码不会破坏数据。 现在假设数据块很复杂，因此它们本身就封装在类对象中，并且这些对象不容易被复制。 现在，如果从某个属性返回此类对象，则外部代码对您的内部代码具有相同的访问权限。 例如，如果返回List ，则每个人都可以向其添加值。 这通常是不合需要的。 这个问题通常使用只读包装器 – 在返回之前将完全访问的内部对象包装在只读包装器中。 这种方法的问题是包装器可能是包装值的不良替换 – 包装器是一个不同的类。 （如果从可修改的类派生只读包装器（或反之亦然），那么任何人都可以将“只读”对象向上/向下转换为可修改对象，从而破坏保护。） 我想要一个模式： 数据（例如， int值）具有“public / read-only API”和“private / modifiable API”。 只有对象创建者才能访问“私有/可修改的API”。 私有/公共API可以具有被动部分（例如方法，属性）和活动部分（例如事件）。 除了在对象创建阶段，不应使用代理。 所有电话都应该是直接的。 从“公共/只读API”（以及最好来自“私有/可修改的API”）访问内部数据应该尽可能直接。 在编写这样的对象时，我不希望堆积大量的包装器。 以下是示例界面： interface IPublicApi { int GetValue(); } interface IPrivateApi { void SetValue(int value); } interface IPrivateConsumer { void OnValueChanged(); //Callback […]