我应该如何规划系统重写的架构？
我计划重写我之前参与过部分工作的当前系统。我这样做是为了学习。下面是对旧系统的描述、新系统的基本架构、我想要遵循的一些最佳实践、我想要实现的目标以及我的问题。
让我解释一下旧系统：
1. SQL Server数据库（未规范化）
2. Palm应用程序（将数据输入数据库）
3. Web 服务 1（Palm 应用程序发送数据以输入数据库）
4. Web 应用程序（将数据输入数据库）- 我创建了这个
5. Web 服务 2（Web 应用程序 1 发送数据以输入数据库）- 我创建了这个
6.网站（直接CRUD数据并打印报告）
让我解释一下我的新系统的架构概念：
1. UI Web 应用程序解决方案 - 替换旧网站。
2. UI Web 应用程序解决方案 - 替换旧的 Web 应用程序和 Palm 应用程序。
3. Web 服务解决方案（使用 WCF）- 替换旧的 Web 服务 1 和 Web 服务 2。
4. 业务对象解决方案 - 业务对象、对数据访问解决方案的代码调用和对业务逻辑解决方案的代码调用将放置在此处。
5. 业务逻辑解决方案 - 业务规则将放置在这里。
6. 数据访问解决方案 - 从数据库获取数据的代码将放置在此处。
7. 数据传输对象解决方案 - 用于传输信息如下： 7.1. 与 Web 服务解决方案之间的 UI 解决方案。
7.2. 与 Business Object Solution 之间的 Web 服务解决方案。
7.3. 数据访问解决方案之间的业务对象解决方案。
让我解释一下我对新系统的最佳实践概念：
1. Web 服务解决方案的单元测试。
2. Business Object 解决方案的单元测试。
3. 业务逻辑的单元测试。
4. 数据访问解决方案的单元测试。
5.单一职责原则
6. 开闭原则
7.里氏替换原理
8.接口隔离原则
9.依赖倒置原则
新系统目标
我希望能够生成干净的代码，其中包含单元测试，集成测试包含整个系统，同时学习设计模式、WCF、TDD、Rhino Mocks、Expression Blend 3、Visual Studio 2010 和 TFS 2010。也想用这个系统作为以后学习新语言比如Rails的参考。
问题
1.根据我所阐述的内容，有人对我的架构有疑问吗？还有更好的想法吗？
2.是否有一些我应该遵循但未列出的最佳实践？
3.我列出的某些最佳实践是否不应遵循？
谢谢您抽出时间！
I am planning to rewrite a current system that I previously worked on a portion of. I am doing this as a learning exercise. Below is a description of the old system, basic architecture of the new system, some best practices I want to follow, the goals I want to acheive and my questions.
Let me explain the old system:
1. SQL Server Database (not normalized)
2. Palm Application (to enter data into the database)
3. Web Service 1 (Palm Application sends data to for entry into database)
4. Web Application (to enter data into the database) - I created this
5. Web service 2 (Web Application 1 sends data to for entry into database) - I created this
6. Website (to CRUD data directly and print reports)
Let me explain my architecture concept for the new system:
1. UI Web Application Solution - Replaces the old Website.
2. UI Web Application Solution - Replaces the old Web Application and Palm Application.
3. Web Service Solution (using WCF) - Replaces the old Web Service 1 and Web Service 2.
4. Business Object Solution - Business object, code calls to Data Access Solution and code calls to Business Logic Solution will be placed here.
5. Business Logic Solution - Business rules will be placed here.
6. Data Access Solution - Code to get data to/from database will be placed here.
7. Data Transfer Object Solution - Used to transfer information as follows:
7.1. UI Solutions to/from Web Service Solution.
7.2. Web Service Solution to/from Business Object Solution.
7.3. Business Object Solution to/from Data Access Solution.
Let me explain my best practice concepts for the new system:
1. Unit tests for Web Service Solution.
2. Unit tests for the Business Object Solution.
3. Unit tests for the Business Logic.
4. Unit tests for the Data Access Solution.
5. Single Responsibility Principle
6. Open/Close Principle
7. Liskov Substitution Principle
8. Interface Segregation Principle
9. Dependancy Inversion Principle
New system goals
My hope is that I am able to generate clean code that has unit tests wrapped around it with integration tests wrapped around the whole system while learning design patterns, WCF, TDD, Rhino Mocks, Expression Blend 3, Visual Studio 2010 and TFS 2010. I would also like to use this system as a reference for learning new languages in the future such as Rails.
Questions
1.Based on what I have layed out, does anyone have issues with my architecture? Any better ideas?
2.Are there certain best practices I should be following that are not listed?
3.Are there certain best practices I listed that should not be followed?
Thank you for you time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
好吧，我对您的系统大小一无所知，但首先请确保您不会遇到 第二个系统效果。
Well, I don't know anything about the size of your system, but first of all make sure you do not run into the 2nd system effect.
我会找到一个更好的“学习”（并且更现实）的项目：使用该系统并重构它，以便提高质量。从头开始，这通常是更好的学习体验。
我认为能够改进/重构系统是软件开发人员作为绿地项目更常见的日常需求。
I would find an even better 'learning' (and more realistic) project: Use the system and refactor it so the quality is improved. It is often a better learning experience as always start from scratch.
I think being able to improve/refactor a system is a much more common daily software-developer's requirement as green-field projects.
架构的主要目的是支持需求，因此在不知道这个特定实例中的需求/用例的情况下，我无法判断您的架构是否好。
话虽如此，您基本上已经描述了一个 3 层的分层应用程序，这通常是一种明智的方法。但是，我不会将其分解为如此多的解决方案（我会有一个 UI、业务和数据层解决方案，其中包含单独的项目）。
我不知道为什么你需要“数据传输解决方案” - 为什么你需要一个单独的库来处理层之间传递的数据？他们应该能够自己在堆栈中从一个调用到另一个调用。
An architecture's primary purpose is to support the requirements, so I cannot say whether your architecture is good or not without knowing the requirements/use cases in this specific instance.
Having said that, you've basically described a 3-tier layered application which is usually a sensible approach. However, I wouldn't have broken it into so many solutions (I'd have had a UI, Business and Data layer solutions with separate projects within them).
I'm not sure why you need the "Data transfer solution" - why do you need a separate library to handle passing data between layers? They should be able to call from one to another down the stack themselves.
首先，我认为你的方法很酷。
你的时间和预算充足吗？
商人的工作可能就是告诉你：你不是。
现在事情变得更严重了：你需要做的是让系统在架构方面一步一步变得更干净。说服（我希望你并不孤单）团队成员这些事情可以减轻他们的生活。
在更改之前编写的单元测试将帮助您保持业务需求不被破坏。
你的计划很好，但我担心你无法一鼓作气地实现它！据我所知，这种情况只发生了 10^100 年。
干得好！
first of all I think your approach is cool.
Are you in time and budget?
The buisness peoples job is probably to tell you: your are'nt.
Now it becomes a little bit more serious: What you need to do is to get the system step by step cleaner, in terms of architecture. Convice (i hope you're not alone) the team members that these things will ease their life.
Unittests written before changes, will help you to keep business requirements unbroken.
Your plan is exellent but I fear you cannot reach it with a big bang! This happens as far as i know only 10^100 years.
Do a good job!