问题标签 [separation-of-concerns]

我无法为这种应用程序找出正确的架构：它是一个图表应用程序，类似于 MS Visio。这些图表用于生成传递给另一个应用程序的数据。

在设计应用程序时，我一直尝试使用分层，但现在我无法决定在数据与表示形式如此紧密耦合的情况下如何做到这一点。例如，我画布中的某个对象有一个 (X,Y) 数据，该数据仅用于演示目的，但必须像域数据一样存储。

我哪里弄错了？我很确定我是从错误的角度看待这个问题，但我无法找出正确的角度。

再次感谢！

更新：

我也知道，在这种情况下，也许我不应该将 UI 与域分开。如果是这样，请向我提供一些关于何时应用分离以及何时不应用的理性。

我一直在为我的 PHP MVC 框架尝试一堆不同的目录结构。在这样做时，我想到了一些将应用程序的不同部分彼此分开的原因。

例如，假设这是我当前的结构：

按照我的方式，我可以简单地通过覆盖/private/framework/目录来更新框架，这不会影响/private/config/中的用户框架配置或/private/libraries/中的第 3 方库。

/index.php文件几乎纯粹用于加载/private/framework/bootstrap.php文件，这意味着更新/private/framework/目录也将更新主引导文件（让我不必更新/ index.php文件，它将保持原样，因为其中根本没有太多内容）。

此外，该应用程序也与与框架有关的所有内容分开，因此用户可以在需要时切换/更改/更新他们的应用程序，而不必担心其他目录。

关于将目录彼此分开以使它们更容易更新，我是否走在正确的轨道上？

我在一些框架中看到他们的框架目录中有/private/libraries/和/private/application/目录......但在我看来，这似乎很难更新到框架的新版本如果需要的话。还是我想错了？

如果您有兴趣，可以在这里查看我以前的目录结构。我的新问题有点不同（希望更好......），就像我的问题一样，所以我认为有必要发布一个新问题。

这不像我希望的那样小问题，但是啊！;)

提前感谢=）

我正在尝试为我的 rails 应用程序进行日志记录，并且对 rails 中使用的哲学存在一些困境。我的应用程序具有以下Link模型has_many Hit：

现在每次点击链接时，我都会调用hit!方法来记录链接上的请求（为了保持控制器瘦，我使模型变胖）：

现在这就是我感到困惑的地方。我想记录对象附带的数据request（如远程 ip、引用者、用户代理等），因此我需要将请求对象传递给模型，但我认为这不符合“关注点分离”和模糊MVC 设计模式中的责任线（当然，如果我错了，请纠正我）。另外，如果我要Hit在控制器本身中创建一个对象，那么我将制作瘦模型和胖控制器：

尽管后一种情况使测试变得更加容易（我不需要在模型规范中模拟请求） - 它似乎并不正确。

对此的任何建议 - 非常感谢。

PSextract_data_from_request(req)方法放置在需要的适当位置。它返回对象所需属性的哈希值Hit。

我是 mvc 新手，整个编程方式对我来说非常陌生，所以要温柔...

我在我的文章存储库中有：

如何在保持关注点分离的同时从界面传递参数类别和位置？

我想过：

并将参数与 Article 对象一起传递，但这意味着我必须在控制器中传递类别和位置。我在这里的方向正确吗？

I learned PHP by hacking away at phpBB2, even submitting a few mods to their database, which others downloaded and used. (I don't believe phpBB2 is supported any more with phpBB3 out so long now, so the v2 mods database is no more.)

One of my favorite things about phpBB was their templates system, which let the editor completely separate the HTML and the PHP. PHP files contained PHP: logic, database queries, and activating the templates. TPL files contained templates: HTML, template variables, and specialized HTML comments to allow for conditional or repeating blocks.

However, any time I see someone's PHP code online, it's either a small snippet working with a single function or such, or the PHP is full of strings containing HTML (or worse, HTML with PHP interspersed). phpBB is the only PHP I've looked at which actually separates the language and the markup language, suggesting to me that few, if any, other PHP codebases do such a thing.

I'm looking to start working with some PHP again, but this time it won't be a phpBB forum, and it will be on a team. Based on my experience, separation of PHP and HTML is uncommon (please correct me if I'm wrong on this!). However, I'm so used to that dividing line, I hate reading mixed PHP and HTML.

In the "real world" of PHP programming, what's the preferred method:

• PHP files with strings of HTML
• HTML files broken up with PHP blocks
• PHP and HTML completely separate (I wish?)
• Something else?

这对大多数人来说似乎很明显，但我只是想确认依赖注入 (DI) 依赖于接口的使用。

更具体地说，对于在其构造函数中具有某个接口作为参数的类或将某个接口定义为属性（又名 Setter）的情况，DI 框架可以移交具体类的实例以满足需求那个类中的那个接口。（如果此描述不清楚，请道歉。我无法正确描述这一点，因为术语/概念对我来说仍然有些新。）

我问的原因是我目前有一个具有某种依赖关系的类。与其说是对象依赖，不如说是 URL。该类看起来像这样 [C#]：

SoapHttpClientProtocol 类有一个名为的公共属性Url（它是一个普通的旧“字符串”），这里的构造函数将它初始化为一个硬编码的值。

我可以使用 DI 框架在构建时注入不同的价值吗？我想不是，因为this.Url不是任何一种Interface；这是一个String。

[顺便说一句，根据我正在使用的代码中的注释，上面的代码是“由 wsdl 自动生成的”。所以我并不特别想更改这段代码，尽管我也没有看到自己重新生成它。所以也许改变这个代码是好的。]

我可以看到自己制作了一个替代构造函数，它将字符串作为参数并this.Url以这种方式初始化，但我不确定这是保持松散耦合关注点分离的正确方法。(系统级芯片)

对这种情况有什么建议吗？

我正在对我在 CakePHP 1.2 下构建的 CakePHP 应用程序进行大修。我已经升级到 1.3 并且正在考虑从我的应用程序的管理路由范式中移除。我发现由于前端和管理员的重复功能，我的一些控制器变得非常大。我的直觉是，创建一组管理控制器并将管理路由全部删除会更简洁，但我想了解其他人在做什么以及我将错过的功能（如果有的话）丢弃路由。

在这方面，健壮的 CakePHP 应用程序（或其他 MVC 框架）的最佳实践是什么？

假设您正在编写一个函数来检查是否通过适当的 URL 访问了页面。该页面有一个“规范”存根 - 例如，虽然可以在 stackoverflow.com/questions/123 访问页面，但我们更愿意（出于 SEO 原因）将其重定向到 stackoverflow.com/questions/123/how-do -i-move-the-turtle-in-logo - 并且实际的重定向安全地包含在它自己的方法中（例如，redirectPage($url)），但是如何正确测试调用它的函数呢？

例如，采用以下函数：

如果您要对 checkStub() 函数进行单元测试，重定向不会妨碍您吗？

这是一个更大问题的一部分，其中某些功能似乎变得太大并离开单元测试领域并进入集成测试领域。我的脑海中立即想到路由器和控制器存在这些问题，因为测试它们必然会导致页面的生成，而不是仅限于它们自己的功能。

我只是在单元测试中失败了吗？

大多数应用程序架构建议似乎都强烈建议只有表示层才能访问 HTTPContext（以促进松散耦合、减少依赖关系、增加可测试性等）。

那么，人们是如何处理 Caching 和 Session 的呢？需要非常具体的数据访问和业务逻辑知识来确定哪些项目需要缓存以最大程度地提高应用程序性能。但是，对于 ASP.Net Web 应用程序，对这些的访问是通过 HTTPContext 提供的。

一种选择是创建一个 CacheFactory 和一个 SessionFactory，以及一个 ICache 和 ISession 接口 - 然后以某种方式使用 DI 原理将 ISession 和 ICache 传递给 BLL 中的每个方法，然后是需要它的 DA 层。

这真的是开发人员最终要做的吗？还有另一种更简单的方法来处理这个问题吗？

感谢您的任何建议。

我正在经历一场职业生涯中期的哲学建筑危机。我看到客户端代码（UI、Web 服务、MVC、MVP 等）和服务层之间的界限非常清晰。然而，从服务层回来的界限越来越模糊。这一切都始于使用 Linq 查询代码的能力和延迟加载的概念。

我创建了一个由合同和实施组成的业务层。然后，实现可以依赖于其他合同等。这是通过带有 DI 的 IoC 容器处理的。有一个服务可以处理 DataAccess，它所做的只是返回一个 UnitOfWork。这个 UnitOfWork 在扩展时创建一个事务，并在 Commit 方法上提交数据。[查看本文（可测试性和实体框架 4.0） ]：

Repository 是通用的，适用于两种实现（EF4 和 InMemory DataStore）。T 由从数据库架构或 EF4 映射生成的 POCO 组成。可测试性内置于存储库设计中。我们可以利用内存中的实现来断言具有预期的结果。

虽然数据源是抽象的，但 IQueryable 仍然使我能够在业务逻辑中的任何位置创建查询。这是一个例子。

现在您可以看到当您使用复杂的过滤器执行连接时，查询如何变得更加复杂。

因此，我的问题是：

1. BLL 和 DAL 之间没有明确的区别是否重要？.
2. 在类似于 InMemory 抽象的 Repository 层后面时，可查询性是否被视为数据访问或业务逻辑？

补充：我想得越多，也许第二个问题是唯一应该问的问题。