Questions tagged «separation-of-concerns»

问题中使用的示例将最少的数据传递给函数，以确定是否用户是管理员的最佳方法。一个常见的答案是： user.isAdmin() 这引起了评论，该评论被重复了多次并被多次投票： 用户不应该确定它是否是管理员。特权或安全系统应该。与课程紧密联系并不意味着将其纳入课程是一个好主意。 我回答， 用户没有决定什么。用户对象/表存储有关每个用户的数据。实际用户不会改变自己的一切。 但这没有效果。显然，存在潜在的视角差异，这导致沟通困难。有人可以向我解释为什么user.isAdmin（）不好，并绘制一个简短的草图来“完成”吗？ 确实，我看不到将安全与受保护系统分开的优势。任何安全性文字都将要求从一开始就将安全性设计到系统中，并在开发，部署，维护乃至报废的每个阶段都要加以考虑。它不是可以固定在侧面的东西。但到目前为止，此评论有17票赞成票，表明我错过了一些重要的内容。

55 design  object-oriented-design  separation-of-concerns  permissions 

首先，我说这不是我的代码也不是我的同事的代码。几年前，当我们的公司规模较小时，我们有一些我们需要做的项目，但我们没有能力，因此将它们外包了。现在，我一般都不会反对外包或承包商，但是他们产生的代码库是大量的WTF。话虽这么说，它确实（大部分）有效，所以我认为它在我所见过的外包项目中排名前10％。 随着我们公司的成长，我们尝试将更多的内部开发工作带入公司。这个特殊的项目落在我的腿上，所以我一直在检查，清理，添加测试等。 我看到有一种模式经常重复出现，而且看起来如此令人恐惧，以至于我想知道是否存在某种原因，而我只是看不到它。模式是一个没有公共方法或成员的对象，只是一个公共构造函数，它可以完成对象的所有工作。 例如，（如果很重要，代码是Java的，但是我希望这是一个更普遍的问题）： public class Foo { private int bar; private String baz; public Foo(File f) { execute(f); } private void execute(File f) { // FTP the file to some hardcoded location, // or parse the file and commit to the database, or whatever } } 如果您想知道，这种类型的代码通常以以下方式调用： for(File f …

49 language-agnostic  separation-of-concerns  constructors 

我的一些同事告诉我，数据库中的存储过程中包含业务逻辑违反了三层分离架构，因为数据库属于数据层，而存储过程是业务逻辑。 我认为如果没有存储过程，世界将变得非常严峻。 他们真的违反了三层分离吗？

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

我的问题与Microsoft引入的MVC设计模式和Razor语法有关。 在学习MVC设计模式时，我被告知该想法是基于称为关注点分离的原理。 但是Razor语法允许我们直接在Views中使用C＃。 这不是问题的交集吗？

22 c#  asp.net-mvc  separation-of-concerns  razor 

对我来说，一个长期存在的问题是：何时将数据（实际值）存储在数据库表中，何时将其正确存储在代码中？ 无法达成共识的通常是这样的（*）： 如果它是单个变量或简单结构，或者是几个值的数组，则将数据放在代码中。 [* 共识已在评论和答案中进行了辩论，但基本上我希望有一个前提来启动这个问题，因此随时可以提出挑战并加以改进 ] 例： $number = 44; $colors = array("blue", "yellow", ... "mauve"); 如果它具有数百行以上相同类型的数据，请使用数据库。 但是似乎有一个灰色地带。那么不清楚的情况又如何呢？做出决定时需要注意哪些注意事项和因素？ 示例： 假设您的公司使用10-15种不同类型的电机框架，它们可以表示为“ 412T”。您大约有30个，并且它们很少更改。您可以为这些数据库创建数据库表，也可以在数据库中对其进行硬编码。在这种情况下，电动机是静态的，物理的东西，不太可能经常改变。 将它们保留在代码中会使它们受到源代码控制，而在数据库中，通常不会跟踪数据库更改。但是将它们保存在数据库中可以从数据中释放（分离）代码。 我可以使用的另一个（实际）示例是我的这个问题：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（当前为48行选项数据）。

17 database  source-code  separation-of-concerns 

我正在开发一个应用程序，它将需要存储inline，intext元数据。我的意思是这样：假设我们有一个长文本，并且我们想存储一些与特定单词或文本句子相关的元数据。 存储此信息的最佳方法是什么？ 我的第一个想法是在文本中包含某种Markdown语法，然后在检索时将对其进行解析。看起来像这样： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[@note this sounds really funny latin] euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. 这会带来两个我想到的问题： 相对较小的是，如果所说的语法恰好在所说的文本上，它可能会使解析混乱。 最重要的是，这不会使此元数据与文本本身保持独立。 我想拥有一个离散的数据结构来保存这些数据，例如一个存储这些元数据的不同的DB表，这样我就可以以离散的方式使用它们：查询，统计信息，排序等等。 编辑：既然回答者删除了他的答案，我认为在这里添加他的建议可能是一件好事，因为这是在第一个概念上扩展的可行建议。海报建议使用类似的语法，但对元数据链接到PRIMARY KEY该的metadata数据库表。 看起来像这样的东西： Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam __nonummy nibh__[15432] euismod tincidunt …

14 data-structures  concepts  separation-of-concerns  markup 

借助AOP，我可以从业务逻辑中删除日志记录代码。但是我认为它只能用于记录简单的事物（即记录方法的进入/退出和参数值）。 但是，如果我需要在业务逻辑中记录一些内容，该怎么办？例如 public void SomeDomainMethod(string id) { //Get user by Id User user = Users.Get(id); if (user == null) { Log.Warn("user is not existed"); //<----------------- Log A throw new InvalidOperationException("user is not existed"); } //Step 1 while(true) { //do something } Log.Info("Step 1 is completed"); //<----------------- Log B //Step 2 …

12 c#  logging  separation-of-concerns 

原来的样子 多年以来，我一直在组织软件解决方案，例如： 数据访问层（DAL），用于抽象访问数据的业务 业务逻辑层（BLL），用于将业务规则应用于数据集，处理身份验证等。 实用程序（Util）只是我逐渐建立的常用实用程序方法的库。 表示层当然可以是Web，桌面，移动等。 现在的样子 在过去的四年左右的时间里，我一直在使用Microsoft的Entity Framework（我主要是.NET开发人员），并且由于Entity Framework已经完成了DAL工作，因此我发现拥有DAL变得越来越麻烦。我的DAL曾经做过的工作：它抽象了针对数据库运行CRUD的业务。 因此，我通常以一个DAL结束，该DAL具有如下方法的集合： public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 然后，在BLL中，该方法将按如下方式使用： public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } 当然，这是一个简单的示例，因为BLL通常会应用多行逻辑，但是在这样有限的范围内维护DAL似乎有点多余。 放弃DAL并像这样简单地编写我的BLL方法会不会更好： public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns 

首先，我阅读了摘自Edsger W. Dijkstra 1974年的论文“关于科学思想的作用”： 让我尝试向您解释，我的品味是所有明智思维的特征。就是说，一个人出于自己的一致性而愿意独立地深入研究其主题的一个方面，一直都知道一个人只在其中一个方面中占据一席之地。我们知道一个程序必须是正确的，我们只能从那个角度研究它；我们也知道它应该是有效的，可以这么说，我们可以在另一天研究它的效率。在另一种情况下，我们可能会问自己，是否这样做：为什么，该程序是理想的。但是，通过同时处理这些各个方面，则无济于事！这就是我有时所说的“关注点分离”，即使不是完全可能，据我所知，这是有效地整理思想的唯一可用技术。这就是我所说的“将注意力集中在某个方面”的意思：这并不意味着忽略其他方面，这只是正视这个事实，即从该方面的观点来看，另一方面是无关紧要的。它同时是一轨和多轨。 我看到关注点的现代分离正在谈论将代码模块化。但是，阅读上面的引用后，我理解这是一次将您的注意力集中在一项特定的任务上，而不是将精力集中在其他方面。在我看来，这并不意味着必须将代码分成模块化的块。 也就是说，在您面前有一个代码，即在一个文件中的所有文件都包含视图，存储库，控制器，事件处理，工厂等概念。 作为一个简短的示例，下面是一些具有数据访问权限并查看（输出）的代码： $sql = "SELECT * FROM product WHERE id = " . db_input($id); $row = db_fetch_array(db_query($sql)); <option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option> 使用现代的OO，我可以使用Repository模式将数据访问放在其自己的文件中，View代码可以进入其自己的文件模板，并且可以将它们连接在一起以通过控制器（或Action或Request Handler）进行通信，并且我可以添加一个工厂来创建和连接各种依赖项。我可以有一个定义这些工厂的配置文件。当然，这与单一文件的一切相去甚远。 我关于关注点分离的问题是这样的：阅读Dijkstra的报价，我有一个想法，即他不一定意味着关注点分离是“代码的模块化分离（到文件或它们自己的函数/方法/等）中”，而且他的意思还在于让人们将注意力集中在程序的某个方面，而不用专心于其他重要但目前尚未考虑的方面，而无论它们是否在代码中物理上分开。 那么为什么我们要负担物理模块化代码分离和设计模式呢？不管代码的结构如何，仅将精力集中在一个方面是否足够？ 我不是在谈论编写最可怕的意大利面条代码，然后只考虑它的一个方面，这很可能是一种负担。但是最后，我要解决的是，当不需要在精神上专注于某个方面时，为什么要执行物理代码分离，为什么要将代码拆分为分离的文件或块（方法）？ 关注点分离应该仍然是一种心理锻炼，而不是身体锻炼吗？ 换句话说，编程的精神（专注）和物理（纸上代码）方面是否应该脱节？

9 design  source-code  separation-of-concerns  modularization  dijkstra