问题标签 [loose-coupling]

我正在使用silverlight 和后端的SQL Server DB 来实现一个基于Web 的应用程序，以获取应用程序将显示的所有数据。我想确保应用程序可以轻松扩展，我觉得这样做的方向是使数据库松散耦合，而不是将所有内容与外键捆绑在一起。我尝试搜索一些示例，但无济于事。

有没有人有任何信息或良好的起点/样本/示例来帮助我着手解决这个问题？

非常感谢帮助。

亲切的问候，

我们有一个大型系统，它通过 Unity 松散地绑定到它的数据源（Navision）——我们有机会将它换掉并拥有我们自己的数据库。

因此，我们环顾四周，非常喜欢 Fluent NHibernate 的外观——我们正在尝试进行概念验证并更换一些服务。

我们想使用 NHibernates HiLo 算法 - 不幸的是，我们从 Navision 继承了字符串 ID，它作为其 ID 的前缀（例如 COL00001），因此为了匹配我们需要使用字符串 ID 的接口。

有谁知道我怎么会得到类似...

在 ID 是字符串的地方工作？我们目前正在获取 Identity must be int, long 等

谢谢，

安迪

- - - 更新 - - -

我尝试了建议的文章中的示例，但此功能已从 Fluent NHibernate 的更高版本中删除 - 但是有一个 .Custom - 但我似乎无法让它工作！

我在 DRY 和松耦合之间左右为难:(

我有两个站点，您可以链接您的帐户，然后这些站点可以共享数据（通过 RESTful api ...）

一个站点是媒体聚合站点，另一个是媒体商店，人们可以在其中购买数字媒体（音乐/照片/视频）。

我的老板想效仿 iTunes 商店，并在聚合站点中有一个内置商店，人们可以在那里购买他们喜欢的东西并将其自动添加到他们的帐户中。

我为商店网站编写了 99% 的模板和视图 (django)，我需要在媒体网站上显示内容。

我应该只渲染模板并将预渲染的 html（通过 api）交付到媒体（聚合）站点，（并遵守 DRY）还是应该交付 json 以避免商店端的紧密耦合的自定义模板？

或者也许混合设计会更好？交付预渲染的 html 块（例如 a 中的前 10 种产品<ol>）并让媒体站点请求它需要的块？

混合设计对我来说似乎最有希望（现在），但可能会导致更多的 api 调用（因此更多的数据库查询）

你怎么看？

编辑 - 一个新想法：（如评论中所见）您如何看待将一些自定义 css 加载到 iframe 中的商店网站？

我认为这应该可以消除混乱，将紧密耦合的代码量减少到 3 行左右的 2 行左右，并且省去了维护几乎相同的两组模板的巨大麻烦。

我有一个电子邮件组件，我正在将其集成到我的应用程序中，寻找一些关于如何围绕它构建包装器的提示，以便我可以在需要时将其与另一个 3rd 方组件交换。

我现在的做法是：

1. 构建一个界面将是我需要的功能。
2. 创建一个实现接口的类，在这个类中使用我的第 3 方组件。

3. 该组件的任何使用都将通过接口进行，例如：

   IPop3 pop3 = new AcmeIncePop3Wrapper(); pop3.connect();

在 AcmeIncePop3Wrapper 内部将是：

这是一个好方法吗？

我可能可以通过使用 ninject 添加另一个抽象，这样我就可以换出实现，但实际上这似乎就是我所需要的，因为我不希望每天都更改 3rd 方程序集，只是不想让事情变得如此紧密耦合。

我的 asp.net 控制器操作将 FormCollection 作为参数。

然后我遍历我自己的集合，在表单集合中查找值等。

我将所有代码移动到我的业务逻辑层，并在我的操作中调用我的业务逻辑层，例如：

但是我对将表单集合传递给我的业务逻辑层感到有点厌倦。

我真的可以在这里选择吗？还有其他想法吗？

还是完全没问题？

我正在阅读 Loose Coupling 及其好处，这些都是非常好的东西，但我开始想知道哪些工具非常适合创建松散耦合的解决方案？首先我想到的是类型和接口以及抽象类，但我确信有很多方法可以提供松散耦合。也许多态有助于创建松散耦合的对象和系统。

谢谢。

正如PMD建议的那样，我想通过使用接口而不是实现来减少合作......

在这种情况下，知道我需要一个可克隆参数，我可以克服克隆困境（接口中没有clone()方法Cloneable）吗？

我发现每当我创建一个层/层时，我必须在一个层之间转换，这是否意味着它是一个紧密耦合的系统？如果我要更改业务逻辑、删除数据库中的字段等，我是否必须将所有层从数据库层更改为客户端前端？

例如，一个 Web 服务公开一个“数据契约”对象，并将其转换为中间层的一些“业务对象”，然后将其转换为数据层中适当的“ORM 对象”。客户端调用 Web 服务，将数据合同转换为一些模型对象，等等......

既然中间有这么多的翻译，那么如何将 Web 服务设计成松耦合的呢？如果有人能分享他/她的意见，那就太好了。

谢谢

从设计和松耦合的角度来看。为项目中可能是组合模型一部分的每个类都有一个接口是个好主意吗？

我有一个项目正在做这件事，但现在我得到了相当多的接口，试图让事情保持相对松散的耦合。

我最近一直在做很多关于 SOA 和 ESB 等的研究。

我现在正在重新设计一些工作中的遗留系统，并希望使用比目前更多的 SOA 架构来构建它。我们在大约 5 个网站中使用这些服务，而我们目前在遗留系统中遇到的最大问题之一是，几乎在我们进行错误修复或更新时，我们需要重新部署我们的 5 个网站，这可能是相当耗时的过程。

我的目标是使服务之间的接口松散耦合，以便无需重新部署所有相关服务和网站即可进行更改。

我需要能够在不破坏或更新其任何依赖项的情况下扩展现有服务接口。你们中有人遇到过这个问题吗？你是怎么解决的？