如果最终架构师想要采用单一项目方法，那么您没有理由不能创建一个包含 BLL 和 DAL 文件夹的 app_code 文件夹来暂时分隔代码，这将帮助您转移到稍后 N 层解决方案。
I would be pushing hard for the N tiered approach even if it's a small project. If you use an ORM tool like codesmith + nettiers you will be able to quickly setup the projects and be developing code that solves your business problems quickly.
It kills me when you start a new project and you spend days sitting around spinning wheels talking about how the "architecture" should be architected. You want to be spending time solving the business problem, not solving problems that other people have solved for you. Using an ORM (it doesn't really matter which one, just pick one and stick to it) to help you get initial traction will help keep you focussed on the goals of the project and not distract you trying to solve "architecture" issues.
If, at the end of the day, the architect wants to go the one project approach, there is no reason you can't create an app_code folder with a BLL and DAL folder to seperate the code for now which will help you move to an N-Tiered solution later.
I guess a fairly big downside is that the extra volume of code that you have to write, manage and maintain for a small project may just be overkill.
It's all down to what's appropriate for the size of the project, the expected life of the final project and the budget! Sometimes, whilst doing things 'properly' is appealing, doing something a little more 'lightweight' can be the right commercial decision!
Because you want the capability of being able to distribute the layers onto different physical tiers (I always use "tier" for physical, and "layer" for logical), you should think twice before just putting everything into one class because you've got major refactorings to do if or when you do need to start distributing.
与任何抽象都会产生复杂性一样，因此执行 N 层的复杂性应该得到适当的证明，例如，N 层实际上对系统有好处吗？ 将会有一些小型系统最适合与 N 层一起工作，尽管其中很多系统不会。
另外，即使您的系统目前很小，您也可能希望稍后向其添加更多功能 - 不采用 N 层可能会给您带来某种技术债务，因此您有要小心。
As with anything abstraction creates complexity, and so the complexity of doing N-tiered should be properly justified, e.g., does N-tiered actually benefit the system? There will be small systems that will work best with N-tiered, although a lot of them will not.
Also, even if your system is small at the moment, you might want to add more features to it later -- not going N-tiered might consitute a sort of technical debt on your part, so you have to be careful.
The only disadvantage is complexity but really how hard is it to add some domain objects and bind to a list of them as opposed to using a dataset. You don't even have to create three seperate projects, you can just create 3 seperate folders within the web app and give each one a namespace like, YourCompany.YourApp.Domain, YourCompany.YourApp.Data, etc.
The big advantage is having a more flexible solution. If you start writing your app as a data centric application, strongly coupling your web forms pages to datasets, you are going to end up doing a lot more work later migrating to a more domain centeric model as your business logic grows in complexity.
Maybe in the short term you focus on a simple solution by creating very simple domain objects and populating them from datasets, then you can add business logic to them as needed and build out a more sophisticated ORM as needed, or use nhibernate.
发布评论
评论（6）
即使这是一个小项目，我也会努力推动 N 分层方法。 如果您使用像 codesmith + nettiers 这样的 ORM 工具，您将能够快速设置项目并开发代码来快速解决您的业务问题。
当你开始一个新项目并花几天时间坐在旋转的轮子周围谈论应该如何构建“架构”时，这让我很伤心。 您希望花时间解决业务问题，而不是解决其他人已经为您解决的问题。 使用 ORM（哪一个并不重要，只需选择一个并坚持下去）来帮助您获得最初的牵引力，这将有助于您专注于项目的目标，而不会分散您尝试解决“架构”问题的注意力。
如果最终架构师想要采用单一项目方法，那么您没有理由不能创建一个包含 BLL 和 DAL 文件夹的 app_code 文件夹来暂时分隔代码，这将帮助您转移到稍后 N 层解决方案。
I would be pushing hard for the N tiered approach even if it's a small project. If you use an ORM tool like codesmith + nettiers you will be able to quickly setup the projects and be developing code that solves your business problems quickly.
It kills me when you start a new project and you spend days sitting around spinning wheels talking about how the "architecture" should be architected. You want to be spending time solving the business problem, not solving problems that other people have solved for you. Using an ORM (it doesn't really matter which one, just pick one and stick to it) to help you get initial traction will help keep you focussed on the goals of the project and not distract you trying to solve "architecture" issues.
If, at the end of the day, the architect wants to go the one project approach, there is no reason you can't create an app_code folder with a BLL and DAL folder to seperate the code for now which will help you move to an N-Tiered solution later.
缺乏经验的团队往往需要更长的时间来构建 3 层。代码更多，因此错误也更多。 但我只是在扮演魔鬼的代言人。
it tends to take an inexperienced team longer to build 3-tier.It's more code, so more bugs. I'm just playing the devil's advocate though.
我认为一个相当大的缺点是，您必须为小型项目编写、管理和维护额外的代码量，这可能是多余的。
这一切都取决于项目的规模、最终项目的预期寿命和预算！ 有时，虽然“正确”地做事很有吸引力，但做一些更“轻量级”的事情可能是正确的商业决定！
I guess a fairly big downside is that the extra volume of code that you have to write, manage and maintain for a small project may just be overkill.
It's all down to what's appropriate for the size of the project, the expected life of the final project and the budget! Sometimes, whilst doing things 'properly' is appealing, doing something a little more 'lightweight' can be the right commercial decision!
因为您希望能够将层分布到不同的物理层（我总是使用“层”表示物理层，使用“层”表示逻辑层），所以在将所有内容放入之前您应该三思而行一类，因为如果或当您确实需要开始分发时，您需要进行重大重构。
Because you want the capability of being able to distribute the layers onto different physical tiers (I always use "tier" for physical, and "layer" for logical), you should think twice before just putting everything into one class because you've got major refactorings to do if or when you do need to start distributing.
与任何抽象都会产生复杂性一样，因此执行 N 层的复杂性应该得到适当的证明，例如，N 层实际上对系统有好处吗？ 将会有一些小型系统最适合与 N 层一起工作，尽管其中很多系统不会。
另外，即使您的系统目前很小，您也可能希望稍后向其添加更多功能 - 不采用 N 层可能会给您带来某种技术债务，因此您有要小心。
As with anything abstraction creates complexity, and so the complexity of doing N-tiered should be properly justified, e.g., does N-tiered actually benefit the system? There will be small systems that will work best with N-tiered, although a lot of them will not.
Also, even if your system is small at the moment, you might want to add more features to it later -- not going N-tiered might consitute a sort of technical debt on your part, so you have to be careful.
唯一的缺点是复杂性，但与使用数据集相比，添加一些域对象并绑定到它们的列表确实有多困难。 您甚至不必创建三个单独的项目，只需在 Web 应用程序中创建 3 个单独的文件夹，并为每个文件夹指定一个命名空间，例如 YourCompany.YourApp.Domain、YourCompany.YourApp.Data 等。
最大的优点是更灵活的解决方案。 如果您开始将应用程序编写为以数据为中心的应用程序，将 Web 表单页面与数据集强耦合，那么随着业务逻辑变得越来越复杂，您最终将需要做更多的工作，迁移到更以领域为中心的模型。
也许在短期内，您通过创建非常简单的域对象并从数据集中填充它们来专注于一个简单的解决方案，然后您可以根据需要向它们添加业务逻辑并根据需要构建更复杂的 ORM，或者使用 nhibernate。
The only disadvantage is complexity but really how hard is it to add some domain objects and bind to a list of them as opposed to using a dataset. You don't even have to create three seperate projects, you can just create 3 seperate folders within the web app and give each one a namespace like, YourCompany.YourApp.Domain, YourCompany.YourApp.Data, etc.
The big advantage is having a more flexible solution. If you start writing your app as a data centric application, strongly coupling your web forms pages to datasets, you are going to end up doing a lot more work later migrating to a more domain centeric model as your business logic grows in complexity.
Maybe in the short term you focus on a simple solution by creating very simple domain objects and populating them from datasets, then you can add business logic to them as needed and build out a more sophisticated ORM as needed, or use nhibernate.