对于小型应用程序是否值得使用 3 层架构
我正在开发一个相对较小的 ASP.NET Web 应用程序，并且想知道是否真的需要采用完整的 n 层架构。 对于尺寸的概念； 大约有20个数据库表。
过去，我使用了 2 层方法，其中业务逻辑和数据访问被组合到一个类库中，并由一个 ASP.NET Web 应用程序形成 UI 层，这似乎工作正常。
是否存在应采用 n 层的阈值大小或某些经验法则？
I'm working on a relatively small asp.net web application and am wondering if there is really a need to employ full n-tier architecture. For an idea of size; there are about 20 database tables.
In the past I have used a 2-tier approach where business logic and data access are grouped together into a single class library with was an asp.net web application forming the UI tier and this seemed to work OK.
Is there a threshold size or some rule of thumb where you should employ n-tier?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
现在可能相对较小，但您认为未来它会增长吗？ 当然，您必须务实，但如果您在单个程序集中已经有自然的关注点分离，那么将其分成两个或多个程序集是相当容易的。 如果类本身结合了业务逻辑和数据访问，那么您手头上的工作就会更多。 但是，我认为，如果需要的话，在一个程序集中编写数据访问逻辑，在另一个程序集中编写业务逻辑（如果需要的话可以并行）几乎不需要做更多的工作，而不是首先将其全部编写在一个地方。
It may be relatively small now but do you think it might grow in the future? Of your course you have to be pragmatic, but if you already have natural separations of concern within your single assembly then it's fairly easy to split that into two or more assemblies. If the classes themselves combine business logic and data access then you have more work on your hands. However, I'd argue that it's almost no more work to write your data access logic in one assembly and your business logic in the other, in parallel if required, than to write it all in one place in the first place.
如果您预计任何形式的增长或变化，现在加强明确的层级将有所帮助。 但是，如果这是您自己的项目，并且您不介意支付更改或紧密集成代码的成本，那么只需像一层一样破解它即可。
一切都与未来的成本有关。 目前，随心所欲地编程是迄今为止最便宜的方法，但不能很好地应对变化。 通过层规划，会产生前期成本，但它可以比第一种方法更好地处理变化并取消整个层的实现。
因此，您的经验法则取决于谁将在何时支付变更费用。
If you anticipate growth or change of any kind, it would help to reinforce explicit tiers now. But if this is your own project and you don't mind ponying up the cost of change or tightly integrated code, then just hack away at it like one layer.
It's all about future cost. In the present, just programming as you go is by far the cheapest, but does not respond to change very well. With the tier planning, there's an upfront cost, but it can handle change and ripping out whole layer implementations better than the first approach can.
So your rule of thumb is governed by who will pay for the change and when.
是的，这是值得的。 您所提议的是一起破解解决方案。 我无法告诉你这给我带来了多少次痛苦和磨难。 硬币的另一面是过度构建解决方案的宇航员开发人员。 您也想避免这种情况。
简单点，构建您的三层，我建议您尝试 LINQ to SQL，它使构建 DAL 变得轻而易举，然后您可以专注于构建一个精简的 UI 和一个能够处理繁重工作的 BLL。 您不会花费太多时间来完成此操作，并且稍后可以进行单元测试。
Yes it is worth it. What you are proposing is hacking a solution together. I can't tell you how many times this has brought me pain and suffering. The other side of that coin is astronaught developers who overbuild their solutions. You want to avoid this as well.
Be simple, build your three layers, I suggest you try out LINQ to SQL, it makes building the DAL a snap, and then you can focus on building a slim UI, and a BLL that will handle the heavy lifting. It won't take you that much longer to do it and it will allow for unit testing later.
我不知道，但我会抛出这一点：如果这个网络应用程序有可能增长（或更改后端）和/或其他人可能最终维护它，我会考虑使用 n分层方法。
Not one that I'm aware of, but I'll throw this out: if there's a chance this web app can grow (or change backends) and/or somebody else may end up maintaining it, I'd consider going with an n-tier approach.
只要保持可能即可。 现在可能有点矫枉过正，但不要让自己陷入不可能的境地。 大规模重构将比从头开始重建花费更长的时间（并且很可能就是从头开始重建）。
我从事的最后一个项目（来得很晚）的编写方式几乎不可能打破层级。 数据逻辑与业务逻辑与表示逻辑交织在一起。 从短期来看，它与以往一样好，因为修复它需要几个月的时间。
将所有内容分开并不是太困难，所以就像我之前所说的那样，只要保持可能即可。
Just keep it possible. It's probably overkill now but don't write yourself into a situation where it's impossible. Refactoring on a large scale will take you longer than rebuilding it from scratch (and will likely be just that, rebuilding from scratch).
The last project I worked on (came in late) was written in a way that breaking up the tiers was practically impossible. Data logic interwoven with business logic interwoven with presentation logic. In the short term, it was as good as it was ever going to be because fixing it would've taken several months.
It's not too difficult to keep everything separated so like I said earlier, just keep it possible.