如何在不设计航天器的情况下正确分离架构中的关注点？
在我的最后一个问题中，我发布了一些示例代码我是如何尝试实现关注点分离的。我收到了一些不错的建议，但我仍然不“明白”，并且无法弄清楚如何设计我的应用程序以在不设计下一个航天飞机的情况下正确分离问题。
我正在开发的网站（慢慢地从旧的 ASP 逐个部分转换而来）规模适中，有几个不同的部分，包括一个商店（每天约 100 个订单），并获得了相当大的流量（约 30 万个唯一用户/月）。我是主要开发人员，最多可能有 2-3 个开发人员也可以在该系统上工作。
考虑到这一点，我不确定我是否需要完整的企业级架构（如果我错了，请纠正我），但由于我将在接下来的几年中处理此代码，我希望它能够表现良好并且易于使用根据需要延长。我正在学习 C#，并尝试从一开始就融入最佳实践。旧的 ASP 网站简直是一团糟，这次我想避免这种情况。
我目前所做的尝试最终是使用一堆 DTO，其中包含验证并调用 DAL 层以进行持久化的服务。这不是故意的，但我认为现在的设置方式是一个完美的贫血域模型。我一直试图通过将 BLL 转换为域对象并仅使用 DTO 在 DAL 和 BO 之间传输数据来解决此问题，但它不起作用。我还根据数据库表/功能将所有 dtos/blls 分开（例如 - YouTube 风格的应用程序 - 我有单独的 DTO/BLL/DAL 用于片段、视频、文件、评论等）。
根据我所读到的内容，我至少需要使用存储库，可能还需要使用接口。这很棒，但我不确定如何继续前进。请帮忙！
In my last question I posted some sample code on how I was trying to achieve separation of concerns. I received some ok advice, but I still just don't "get it" and can't figure out how to design my app to properly separate concerns without designing the next space shuttle.
The site I am working on (slowly converting from old ASP section by section) is moderately sized with several different sections including a store (with ~100 orders per day) and gets a decent amount of traffic (~300k uniques/month). I am the primary developer and there might be at most 2-3 devs that will also work on the system.
With this in mind, I am not sure I need full enterprise level architecture (correct me if i am wrong), but since I will be working on this code for the next few years, I want it to perform well and also be easy to extend as needed. I am learning C# and trying to incorporate best practices from the beginning. The old ASP site was a spaghetti mess and I want to avoid that this time around.
My current stab at doing this ended up being a bunch of DTOs with services that validate and make calls to a DAL layer to persist. It was not intentional, but I think the way it is setup now is a perfect anemic domain model. I have been trying to combat this by turning my BLL to domain objects and only use the DTOs to transfer data between the DAL and BO, but it is just not working. I also had all my dtos/blls split up according to the database tables / functionality (eg - YouTube style app - I have separate DTO/BLL/DAL for segments, videos, files, comments, etc).
From what I have been reading, I need to be at least using repositories and probably interfaces as well. This is great, but I am unsure how to move forward. Please help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，您有四点需要解决：
(1)“考虑到这一点，我不确定我是否需要完整的企业级架构”
让我们首先处理高层的问题。这取决于“完整的企业级架构”的含义，但简短的答案是“是”，您需要解决系统的许多方面（并且这将取决于系统的上下文，即主要方面是什么） 。如果不出意外的话，关键就是改变和支持性。您需要以支持未来变化的方式构建应用程序（关注点的逻辑和物理分离（依赖注入对于后者来说非常有用）；模块化设计等）。
(2)“如何在不设计航天器的情况下正确分离架构中的关注点？”
我喜欢这种方法（这是我写的一篇文章，总结了我迄今为止学到的所有内容） - 但要点如下：
看看这个，您将至少有六个程序集 - 这并不大。如果您可以将您的系统（单独的关注点）分解为这些大桶，那么它应该能够满足您的需求。
(3) 细节
将关注点分离到不同的层和类中固然很好，但如果您希望能够有效地应对变化，您需要做的更进一步。 依赖倒置 (DI) 是此处使用的关键工具。当我学习 DI 时，这是一件手动的事情（如上一个链接所示），但现在有很多框架（等等）。如果您是 DI 新手（并且您在 .Net 中工作），本文将引导您了解基础知识。
(4) 如何前进
使用 DI 等获得一个简单的垂直切片（UI 一直到 DB）。当您这样做时，您还将构建框架的骨架（您的系统将使用的子系统和主要管道）。
在第二片上开始工作；此时，您应该发现任何您无意中没有重用应重用的东西的地方 - 现在是在构建切片 3,4 和 5 之前更改这些内容的时候 - 在进行太多返工之前。
评论更新：
我不知道，但要回答“是”，您需要能够用“是”回答以下问题：
是的。项目与程序集一一对应，因此，为了获得松散耦合的好处，您肯定会希望以这种方式分离事物，并且要小心如何设置引用。
DTO 不是富域对象。但是，人们似乎可以互换使用 POCO 和 DTO 这两个术语，但严格来说，它们并非如此——如果您来自 Martin Fowler 学派。在他看来，DTO 是一堆 POCO（或其他对象（？）），它们打包在一起用于“通过线路”发送，这样您只需对某个外部系统进行一次调用，而不是进行大量调用。
管理依赖关系。你不希望你的 UI 引用物理数据结构，因为一旦它发生变化（而且它会发生变化），你就会（使用技术术语）被搞砸。这就是分层的全部要点。您想要做的是让 UI 依赖于抽象 - 而不是实现。在 5 层架构中，POCO 可以安全地用于此目的，因为它们是“某些事物”（业务概念）的抽象/逻辑定义，因此只有在存在业务原因时才应该更改 - 因此从这个意义上说，它们相当稳定且更安全可靠。
From what I can see you have four points that need addressing:
(1) "With this in mind, I am not sure I need full enterprise level architecture"
Lets deal with the high level fluff first. It depends on what you mean by "full enterprise level architecture", but the short answer is "Yes" you need to address many aspects of the system (and it will depend on the context of the system as to what the main ones are). If nothing else, the keys ones would be Change and Supportability. You need to structure the application in a way that supports changes in the future (logical and physical separation of concerns (Dependency Injection is a great for the latter); modular design, etc).
(2) "How to properly separate concerns in my architecture without designing a spacecraft?"
I like this approach (it's an article I wrote that distilled everything I had learnt up to that point) - but here's the gist:
Looking at this you'll have a minimum of six assemblies - and that's not huge. If you can break your system down (separate concerns) into these large buckets it should go a long way to giving what you need.
(3) Detail
Separating concerns into different layers and classes is great but you need to go further than that if you want to be able to effectively deal with change. Dependency Inversion (DI) is a key tool to use here. When I learnt DI it was a hand-rolled affair (as shown in the previous link) but there are lots of frameworks (etc) for it now. If you're new to DI (and you work in .Net) the article will step you through the basics.
(4) How to move forward
Get a simple vertical slice (UI all the way to the DB) working using DI, etc. As you do this you'll also be building the bones of the framework (sub-systems and major plumbing) that your system will use.
Having got that working start on a second slice; it's at this point that you should uncover any places where you're inadvertently not reusing things you should be - this is the time to change those before you build slices 3,4 and 5 - before there's too much rework.
Updates for Comments:
I have no idea, but for the answer to be 'yes' you'd need to be able to answer these following questions with 'yes':
Yes. Projects map 1-to-1 with assemblies, so get the benefits of loose-coupling you'll definitely want to separate things that way, and be careful how you set references.
DTO not Rich Domain Object. BUT, people seem yo use the terms POCO and DTO interchangeably when strictly speaking they aren't - if you're from the Martin Fowler school of thought. In his view a DTO would be a bunch of POCO's (or other objects(?)) parcelled together for sending "across the wire" so that you only make one call to some external system and not lots of calls.
Managing dependencies. What you don't want is for you UI to reference the physical data structure because as soon as that changes (and it will) you'll be (to use the technical term) screwed. This is the whole point of layering. What you want to do is have the UI depend on abstractions - not implementations. In the 5-Layer Architecture the POCOs are safe to use for that because they are an abstract / logical definition of 'some thing' (a business concept) and so they should only change if there is a business reason - so in that sense they are fairly stable and safer to depend on.
如果您正在重写电子商务网站，您至少应该考虑用标准包替换它。
现在还有更多这样的软件包可供使用。因此，尽管构建原始网站的决定可能是正确的，但构建自定义应用程序可能不再是正确的决定。
这里列出了几个电子商务平台： 适用于 Java 或.NET
成本应该比2-3个开发者的工资低很多。
If you are in the process of rewriting your eCommerce site, you should atleast consider replacing it with a standard package.
There are many more such packages available today. So although the decision to build the original site may have been correct, it is possible that building a custom app is no longer the correct decision.
There are several eConmmerce platforms listed here: Good e-commerce platform for Java or .NET
It should cost much less than the wages of 2-3 developers.