Tag: 体系结构

设计具有表示层和基于Web服务的API的系统

我们正在设计一个系统，其function在表示层和公开的API层基本相同。 我的问题是使用什么技术/策略，以便我们可以在考虑性能的情况下从代码中获得最多的重用？ 这是一个简化的例子： 用户可以通过Web表单添加客户 。 这将触发Customer.Create（）方法。 API使用者/用户可以通过SOAP / HTTP-POST将客户添加到将调用Customer.Create（）方法的Web服务。 想象一下这些层： PRESENTATION | | WEB SERVICE API (Customer.Create() is available here | | FACADE Business Object Interface – Customer.Create() signature is here | | BUSINESS Business object – Customer.Create method() is fleshed out here | | DATA ACCESS – Writes data 表示层SOAP调用Create（）Web方法，该方法调用Facade的Create（）方法，该方法调用业务对象的Create（）方法，该方法通过数据访问层连接。 问题： 是否关注在表示层中使用API​​的Web服务的性能，或者是否有将表示层直接连接到外观的替代方法？ 如果是这样，使用什么技术（WCF，远程处理，Web服务等）？ 如果您需要更多说明，请与我们联系。 […]

插件架构中的reflection与属性

我正在开发一个从子目录启动时加载插件的应用程序，目前我通过使用reflection来迭代每个程序集的类型并查找实现IPluginModule接口的公共类。 由于Reflection涉及性能损失，并且我希望在一段时间后会有几个插件，我想知道在程序集级别定义应用的自定义属性是否有用，可以在迭代类型之前进行检查（可能是程序集中的十几种类型，包括IPluginModule的1个实现者。 该属性（如果存在）可以提供返回所需类型或实例的方法，然后迭代类型将只是一个回退机制。 在配置文件中存储类型信息不是一种选择。 这会改善性能，还是与实际从存储加载组件的时间相比无关紧要？ 此外，这种用法是否适用于属性？

通用的多层数据访问模式？

我一直在玩一些用于n层数据访问的新模式，并且遇到了一个看起来非常灵活且易于实现的模式。 基本上，我需要一个可以在运行中使各种数据层可插拔/交换的解决方案 – 即从DB进行基本数据访问，分布式缓存，本地缓存等。 下面的代码很容易重复使用并且效率极高 – 只比我以前完全硬编码的解决方案长几个小时。 这看起来怎么样？ 有没有什么办法可以更好地实施？ 任何一般的想法或批评？ 那些使用类似模式的人的任何输入？ 基类： public class DataAdapterFactory where T : class { private DataAdapter Adapter; public DataAdapterFactory(DataAdapterBase Base) { Adapter = Base; } public void Extend() where U : DataAdapterExtender, T, new() { DataAdapterExtender Extender = new U(); Extender.BaseAdapter = Adapter as T; Adapter = Extender; } […]

带有订户缓存的WCF Pub / Sub

问题：如何使用WCF提供分布式，可扩展和抗灾的发布/订阅服务。 细节： 请注意，除了消息/中间件解决方案（如Tibco EMS）之外，还考虑采用此方法。 我一直在研究WCF，特别是它如何用于提供pub / sub。 关于这个主题，这篇文章非常好： WCF pub-sub 。 在文章中，作者试图解决拥有多个发布者的问题（就像在几个框中扩展服务层一样）。 问题是如果客户端A向发布者A注册但发布者B希望发布事件，则发布者B将不知道客户端A.即没有人告诉发布者B客户端A想要被通知事件。 作者建议将pub / sub服务作为解决方案。 发布/订阅服务将集中存储订阅。 但是，如果我想通过二级/双发布/订阅服务使pub / sub服务具有抗灾能力，那么我就有了同样的原始问题。 所以，我认为这个问题有几个解决方案： 将订户详细信息存储在分布式缓存中（请参阅问题： q1和q2 ）。 将订户详细信息存储在数据库/中央文件系统中。 任何人都可以想到任何其他解决方案（即我没有错过WCF的一些奇妙的神奇function？）任何评论赞赏。

使用属性调用方法

我有各种各样的方法，在继续自己的实现之前都需要执行相同的function。 现在我可以在每个方法中实现这些函数，但我想知道是否有办法利用attributes来执行此操作？ 作为一个非常简单的示例，所有网络呼叫都必须检查网络连接。 public void GetPage(string url) { if(IsNetworkConnected()) … else … } 这可以工作，但我必须为使用网络的每个方法调用IsNetworkConnected方法并单独处理它。 相反，我想这样做 [NetworkCall] public void GetPage(string url) { … } 如果网络不可用，则会调用错误方法，并忽略GetPage ，否则将调用GetPage 。 这听起来非常像Aspect Orientated Programming，但我不想为几个调用实现整个框架。 这更像是一个学习练习而不是实现练习，所以我很好奇这样的事情是如何最好地实现的。

这是n层架构的正确实现吗？

我在过去一年左右的时间里一直在学习C＃，并试图在整个过程中融入最佳实践。 在StackOverflow和其他网络资源之间，我认为我正在正确地分离我的问题，但现在我有一些疑虑，并希望确保我走在正确的道路上，然后我将整个网站转换为这个新的建筑。 当前的网站是旧的ASP VBscript并且有一个非常难看的现有数据库（没有外键等），所以至少对于.NET中的第一个版本我不想使用，并且此时必须学习任何ORM工具。 我有以下项目在单独的命名空间和设置中，以便UI层只能看到DTO和业务层，而数据层只能从业务层看到。 这是一个简单的例子： productDTO.cs public class ProductDTO { public int ProductId { get; set; } public string Name { get; set; } public ProductDTO() { ProductId = 0; Name = String.Empty; } } productBLL.cs public class ProductBLL { public ProductDTO GetProductByProductId(int productId) { //validate the input return ProductDAL.GetProductByProductId(productId); } public List GetAllProducts() […]

使用LINQ to SQL的.NET体系结构的最佳设计实践（DAL是否必要？我们能否真正使用POCO？采用设计模式？）

我正避免在.net arch / n-tier体系结构上编写看起来像另一个线程的东西，但请耐心等待。 在选择用于企业应用程序的体系结构时，我希望与其他人一样，对于采用当今趋势和新兴技术的最佳方法仍然不是100％满意或明确。 我想我正在寻求大众社区对于在使用当今.NET技术的大多数方面构建企业应用程序时所选择的方向和架构实现的意见以及您将采取的方向。 我最好把这个关于我和我的问题，因为担心这样做太模糊了; 我想改进我的架构以进行改进，并且非常希望听到你们的想法，因为我将要编写的技术列表。 您建议的任何和所有最佳实践和架构模式都是受欢迎的，如果您之前已经为类似类型的设置创建了解决方案，那么您可能遇到或克服的任何陷阱或警告。 这是我最新项目中采用的技术列表，除了WPF之外几乎所有东西都是:) 智能客户端（WinForms） WCF 由Smart Client使用 ASP.NET MVC 管理工具 客户端工具 LINQ to SQL 由WCF使用 使用ASP.NET MVC Microsoft SQL Server 2008 要考虑的实用程序和其他组件： dependency injection – StructureMap exception管理 – 自定义 unit testing – MBUnit 我目前在n-Tier拱门中运行。 采用基于服务的设计模式，利用请求/响应（不确定它的正式名称）和存储库模式，我的大部分结构都是从Rob Conery的Storefront采用的 。 我想我对大多数层级都或多或少感到高兴（这真的只是DAL，我有点不安）。 在我结束之前，这些是我当前架构面临的真正问题： 如果我在使用LINQ to SQL时应该有一个自定义数据访问层，那么我有一个很大的问号。 我应该直接在服务/业务层或存储库方法的DAL中执行LINQ to SQL吗？ 您是否应该在每个存储库方法调用中创建数据库上下文的新实例（使用using（））？ 或一个类构造函数/通过DI？ 在使用LINQ […]

如果ObjectDataSource不是大型应用程序的答案，那是什么？

引用Andrew Hare对此 问题的回答 。 对象数据源适用于小型项目，但由于您在应用程序的UI层中嵌入数据层信息，因此它们无法很好地扩展。 我建议您只将它们用于非常小的应用程序和便笺式测试。 如果您做出设计决定使用它们，请准备好在将来解决扩展和维护问题。 应用程序架构=可维护性+可伸缩性+ …… 我认为，我读过的每篇开始学习应用程序架构的文章都使用了一些类来构建业务数据层，并使用ObjectDataSource将表示层与业务层连接起来。 看起来我错了。 什么是用于业务层及其与表示层的连接的最佳方法？

如何解耦模式切换和命令

如何将模式（通常由枚举表示）与命令及其关系中的实现分离？ 它们是一个很好的模式，用于描述模式开关（int，enum，string，…）与其命令调用之间的松散绑定吗？ 我想通过配置添加模式，因此必须（动态）轻松扩展（无需编程）。 我已经知道命令模式（C＃/ .Net中的ICommand）。 它可能是一个命令字典及其相关的模式编号，但是切换逻辑呢？

在事务中仅更新大型业务对象的1个字段的最佳方法是什么？

我处于必须执行事务主详细记录的情况下（ 删除上一页详细信息，插入新详细信息，更新主站状态 ） Master Business Object有20个字段 详细信息Business Object仅有4个字段 现在我必须只更新主表中的1个字段和详细信息表中的4个字段以进行插入。 如果我初始化一个新的主对象，则会浪费19个字段进行简单更新。 我该怎样做才能有效地处理这种情况？ 我可以创建一个新对象并仅从我的主业务对象inheritance一个字段吗？ 如果你告诉我DTO或inheritance的东西，请给我一个小的工作实例。 谢谢。