到底是不是所有的设计都难以维护？

Question

我已经看过并考虑过我的过去设计的好坏点，并考虑我的下一个冒险和应该是什么。大家都说MVC和其他人说一个设计不适合所有人。框架对我的项目帮助不大，主要是因为遗留数据库，我过去的想法在当时并不可怕。有一件事我已经证实。所有的设计模式都很难维护。

考虑传统的asp和jsp，您可以在一个页面中混合代码并发布html。有人说添加一列，这很容易做到。更改数据库，添加到您的SQL语句，添加新的HTML，几乎都在那里。如果我有DAL和BLL和UI，我有很多地方可以改变它。如果我有一个ORM的MVC，很多地方。所以对于设计并不坏的小改动。当经历很多变化时，经典变得糟糕，我有很多变化。

当webforms出现时，我得到了更多与事物分离，但改变事情仍然工作，只是在不同层次。我从来没有一个“设计师”，所以把UI网页发送给设计师，就像所有的书籍一样，没有发送逻辑，这对我来说真的没什么大不了的。我确信它对某人有用。无论如何，我接受它是“正确的”，因为微软这么说。

然后MS里面的每个人都决定推送MVC，我发现MS没有发明MVC，图层分离等等。 MVC似乎非常好，但并不容易。每种变化手段都会在各种层次上发生变化。

到最后所有的设计模式，MVC，无设计，DAL，无DAL，BLL等难以使用和维护。没有什么是容易的这是艰苦的工作。我希望我能看到这个盛大的设计，但我看到了所有的困难。 “易于维护”似乎是一个相对术语。

到底是不是所有的设计都难以维护？

Answer 1

所有设计的问题是，您正在为最先进的使用案例+您认为将来可能发生的一些使用案例制作它们。我的经验表明，所要求的新功能在以前几乎从未想过，无论使用何种设计，系统都必须深入触及。

让深层次变化更简单的少数事情之一是DRY（不要重复自己）原则。如果你正在改变某些东西，那么如果你只需要改变一次，这将是一个很大的帮助。设计模式应该有助于避免重复自己，因此它们通常比“混杂”方法更受欢迎。但是，如果您以不重复自己并使其可读性的方式编写混合代码，则其维护成本可能会等于或优于MVC应用程序的维护成本。

Answer 2

可以设计一个长期维护的项目。我听到的最好建议是封装变化* 。如果你设计你的代码，以便最容易修改的部分是最容易改变的部分，那么你的维护头痛将会减少。

当然，总是有可能（几乎可以肯定的是，对于长效产品），您未考虑的事情将不得不改变。

在这方面，任何值得的项目，产品或过程将变得越来越难以维持随着时间的推移。没有什么可以天长地久！

*从Bruce Eckel's“Thinking in ...”系列书籍。

Answer 3

考虑老经典ASP和JSP哪里 你混合代码和产生HTML都在同一个页面 。有人说添加一个专栏和 真的很容易做到。

我不同意这一点。我得到了这个确切的请求，经过几个小时的挣扎后，我决定只是将新的信息添加到现有的列。问题在于根据条件显示和隐藏了某些列，并且每个列的内容也发生了变化。而不是说Table.Columns["price"].Visible = false;，我不得不反向工程嵌套if s的意大利面条代码插入一个与其标题对齐的列。显然，可以编写更清晰的经典ASP，但抽象是一种可用于善或恶的工具，与其他任何工具一样。