确定将代码分解到不同文件夹和命名空间的最佳方法
我有以下目录：
-UI
-业务逻辑
-数据访问
-BusinessObjects
如果我有一个类是服务器端服务的客户端存根，它会更改服务器系统上的状态，那么它会去哪里。 。
i have the following directories:
-UI
-BusinessLogic
-DataAccess
-BusinessObjects
if i have a class that is a client stub to a server side service that changes state on a server system, where would that go . .
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这段代码属于回收站；-)
严重的是，如果你编写了它并且不知道它去了哪里，那么要么代码有问题，要么你的分区有问题； 我们如何才能比您拥有更多有关您系统的信息？
现在，如果您只是想要一些不知情的意见，我们已经得到了 PB 级的意见：
如果您告诉我们存根实际上做了什么，将会更有帮助； 没有具体细节，很难知道它属于哪里，和/或很容易在真空中争论它“应该”属于哪里
this code belongs in the recycle bin ;-)
seriously, if you wrote it and don't know where it goes, then either the code is questionable or your partitioning is questionable; how are we supposed to have more information about your system than you have?
now if you just want some uninformed opinions, those we've got by the petabyte:
it would be more helpful if you told us what the stub actually does; without specifics it is hard to know where it belongs, and/or it is easy to argue in a vacuum about where it "should" belong
我认为这是一种数据访问形式，尽管我不清楚您是否需要将其与其他数据访问类放在同一个项目中。 请记住，这些层主要是概念性的——帮助您保持设计简洁。 将它们分成不同的项目有助于组织，但不是强制性的。 如果它是一个实际的存根类，那么数据访问项目可能是它的自然归宿，但如果它仅在 UI 层中使用，那么将其保留在那里可能就可以了。
I would consider this a form of data access, although it's not clear to me that you need to put it in the same project as the rest of your data access classes. Remember that the layers are mainly conceptual -- to help you keep your design clean. Separating them into different projects helps organizationally, but is not mandatory. If it's an actual stub class, then the data access project is probably the natural home for it, but if it's only used in the UI layer, then keeping it there would probably be ok.
我认为它不属于其中任何一个。 您要么需要一个新目录，要么需要一个全新的项目。 但在给出的这些中，我不得不说 BusinessObjects，因为它肯定不会根据您的描述访问数据，而只是像本地对象（存根）一样工作。
I don't think it belongs in any of those. You either need a new directory or a new project entirely. But out of those given, I would have to say BusinessObjects because it's certainly not accessing data according to your description, and rather is simply acting like a local object (stub).
在 Web 服务存储库中。
In a web service repository.