命名空间/解决方案结构 [英] Namespace/solution structure

问题描述

我很抱歉提出如此笼统的问题，但这对我来说可能具有挑战性.我的团队即将开始一个大型项目，希望将多年来发展起来的所有随机一次性代码库拖到一起.鉴于该项目将涵盖整个公司(客户"、员工")、小任务、控制小任务的大任务和公用事业服务的标准化逻辑实体，我正在努力找出构建命名空间和代码结构.

I apologize for asking such a generalized question, but it's something that can prove challenging for me. My team is about to embark on a large project that will hopefully drag together all of the random one-off codebases that have evolved through the years. Given that this project will cover standardizing logical entities across the company ("Customer", "Employee"), small tasks, large tasks that control the small tasks, and utility services, I'm struggling to figure out the best way to structure the namespaces and code structure.

虽然我想我没有给你足够的细节来继续，你是否有任何关于如何合理地拆分域的资源或建议?如果有帮助，大部分功能将通过网络服务显示，我们是一家 Microsoft 商店，提供所有最新的小玩意和小工具.

Though I guess I'm not giving you enough specifics to go on, do you have any resources or advice on how to approach splitting your domains up logically? In case it helps, most of this functionality will be revealed via web services, and we're a Microsoft shop with all the latest gizmos and gadgets.

• 我正在讨论一个包含子项目的大型解决方案，以简化引用，但这会使其过于笨拙吗?
• 我应该结束遗留应用程序的功能，还是在命名空间中完全不可知(例如，创建一个 OurCRMProduct.Customer 类与一个通用的 Customer 类)?
• 每个服务/项目应该有自己的 BAL 和 DAL，还是应该是一个完全独立的程序集，所有内容都引用?

• I'm debating one massive solution with subprojects to make references easier, but will that make it too unwieldy?
• Should I wrap up legacy application functionality, or leave that completely agnostic in the namespace (making an OurCRMProduct.Customer class versus a generic Customer class, for instance)?
• Should each service/project have its own BAL and DAL, or should that be an entirely separate assembly that everything references?

我没有组织如此影响深远的项目的经验，只有一次性的，所以我正在寻找我能得到的任何指导.

I don't have experience with organizing such far-reaching projects, only one-offs, so I'm looking for any guidance I can get.

推荐答案

给猫剥皮的方法有一百万种.然而，最简单的总是最好的.哪种方式对您来说最简单?取决于您的要求.但我遵循一些一般的经验法则.

There's a million ways to skin a cat. However, the simplest one is always the best. Which way is the simplest for you? Depends on your requirements. But there are some general rules of thumb I follow.

首先，尽可能减少项目总数.当您一天编译 20 次时，额外的一分钟就会加起来.

First, reduce the overall number of projects as much as possible. When you compile twenty times a day, that extra minute adds up.

如果您的应用是为可扩展性而设计的，请考虑按照设计与实现的路线拆分您的程序集.将您的接口和基类放在公共程序集中.为您公司的这些类的实现创建一个程序集.

If your app is designed for extensibility, consider splitting your assemblies along the lines of design vs. implementation. Place your interfaces and base classes in a public assembly. Create an assembly for your company's implementations of these classes.

对于大型应用程序，请将 UI 逻辑和业务逻辑分开.

For large applications, keep your UI logic and business logic separate.

简化您的解决方案.如果它看起来太复杂，它可能是.合并，减少.

SIMPLIFY your solution. If it looks too complex, it probably is. Combine, reduce.

这篇关于命名空间/解决方案结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！