什么是“标准框架”？我们应该构建的代码？
我们的情况是，我们有 4 名开发人员，他们有一些空闲时间（大约 3-4 周）。
在我们的代码库中，对于不同的项目，有许多框架类型的代码，我们启动的每个新项目都会重新编写。由于我们有一些空闲时间，我正在创建一组所有项目都可以重复使用的“标准”库，例如：
- 缓存
- 日志记录
虽然上面的这两个库将依赖于企业库等库，每个新项目都会围绕它编写自己的包装器，等等，因此我们正在整合所有这些代码。
我正在寻找有关您内部构建的在许多项目之间共享的标准库的建议。
为了给您提供一些背景信息，我们构建了 LOB 内部应用程序和面向公众的网站 - 即我们不是销售收缩包装的软件公司，因此我们不需要许可模块之类的东西。
任何想法都将不胜感激 - 我们的开发人员渴望编写一些代码，我非常乐意为他们提供一些从长远来看有利于组织的事情。
干杯
We are in a situation whereby we have 4 developers with a bit of free time on our hands (talking about 3-4 weeks).
Across our code base, for different projects, there are a number of framework-y type of code that is re-written for every new project that we start. Since we have some free time on our hands, I'm in the process of creating a "standard" set of libraries that all projects can re-use, such as:
- Caching
- Logging
Although these 2 above would rely on libraries such as Enterprise Library, each new project would write its own wrappers around it, etc, so we're consolidating all these code.
I'm looking for suggestions on the standard libraries that you built in-house that is shared across many projects.
To give you some context, we build LOB internal apps and public facing websites - i.e. we are not a software house selling shrink-wrap, so we don't need stuff like a licensing module.
Any thoughts would be much appreciated - our developers are yearning to write some code, and I would very much love to give them something to do that would benefit the organization in the long run.
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我们所做的一些主要工作：
希望有帮助
Some of the major things we do:
Hope that helps
好吧，最重要的是，不要重新发明轮子！
花一些时间研究您可以轻松利用的库：
另外，看看Inversion of Control Containers，我推荐Castle Windsor。
接下来，编写一些包装器：
这些应该是您 API 的入口点（公共库，但将其视为 API）。
专注于抽象您在 API 中内部使用的所有库，因此，如果您不想再使用 Log4Net 或 Castle Windsor，您可以通过编写结构良好的抽象并专注于松散耦合的设计模式。
采用域驱动开发：
将 API 视为域和模块化抽象，在内部使用其他常见 API（例如常见数据访问库）。
建议：
我会从一个超级灵活的通用 DAL 库开始，它使得访问任何类型的数据和多种存储介质变得非常容易。
我将使用 Fluent nHibernate 来处理关系数据库，并且将所有方法调用到数据访问实现 LINQ 中，因为它是 ac# 语言功能。
使用 LINQ 查询数据库、索引、文件、xml 等。
ok, most importantly, don't reinvent the wheel!
Spend some time researching libraries which you can easily leverage:
Also, take a look at Inversion of Control Containers, I recommend Castle Windsor.
Next, write some wrappers:
These should be the entry point of you API (common library, but think of it as an API).
Focus on abstracting all the libraries you use internally in your API, so if you don't want to use Log4Net, or Castle Windsor anymore, you can by writing well structured abstractions and concentrating on loosely coupled design patterns.
Adopt Domain Driven Development:
Think of API(s) as Domains and modular abstractions that internally use other common APIs like you common Data Access library.
Suggestions:
I'd start with a super flexible general DAL library, that makes it super easy to access any type of data and multiple storage mediums.
I'd use Fluent nHibernate for the relational DB stuff, and I'd have all the method calls into the you data access implement LINQ, as it's a c# language feature.
using LINQ to query DBs, Indexes, files, xml etc.
有一件事情可以让所有开发人员忙上一个月：
现在，如果系统不是使用 TDD 编写的，那么它很可能会非常单一，并且需要进行大量重构才能引入测试面。希望最终你能得到一个更加模块化、耦合性更少的产品。更具可测试性的系统。
Here is one thing that can keep all developers busy for a month:
Now, if the system was not written using TDD, chances are it'd be very monolithic and will require significant refactoring to introduce test surfaces. Hopefully, at the end of it you end up with a more modular, less tightly coupled. more testable system.
我的态度是，人们几乎不应该编写标准库。相反，我们应该重构现有的工作代码，以消除重复并提高易用性和测试的简易性。
结果将非常像“标准库”，除了您会知道它可以工作（每次更改后都重新运行单元测试，对吗？），并且您会知道它将被使用，因为它已经正在被使用。否则，您将面临创建一个出色的标准库但未被使用并且在使用时无法工作的风险。
My attitude is that one should almost never write standard libraries. Instead, one should refactor existing, working code to remove duplication and improve ease of use and ease of testing.
The result will be very much like a "standard library", except that you will know that it works (you reran your unit tests after every change, right?), and you'll know that it will be used, since it was already being used. Otherwise, you run the risk of creating a wonderful standard library that isn't used and doesn't work when it is used.
之前的工作在业务部门整理下一个版本时遇到了一些停机时间。我们做了一些事情，帮助
我现在要做的其他事情可能是
查看 Resharper HTH
A previous job encountered a little down time while the business sorted out what the next version should be. There were a few things we did that helped
Other things I would do now might be
HTH