我刚来公司(两个星期)，所以我们正在使用来自DotNetNuke的.NET 3.5 Team Foundation为我们的系统启动一个新平台。我们的"建筑师"建议我们使用一个类项目。当然，我采用"三层"架构(业务，数据，Web类项目)来回击。

使用这种架构有什么缺点吗？专业人士将代码与数据分离，使类对象远离代码，等等。

解决方案

回答

缺乏经验的团队可能会花更长的时间来构建3层代码，这是更多的代码，因此还有更多的错误。我只是在扮演魔鬼的拥护者。

回答

我认为一个很大的缺点是，我们必须为一个小项目编写，管理和维护的额外代码量可能是过大的。

这完全取决于项目的大小，最终项目的预期寿命和预算！有时，虽然"适当地"做事很吸引人，但做一些"轻量级"的事可能是正确的商业决策！

回答

即使这是一个小项目，我也将努力争取N层方法。如果我们使用诸如Codesmith + Nettiers之类的ORM工具，则将能够快速设置项目并开发可快速解决业务问题的代码。

当我们开始一个新项目时，我们花了几天时间坐在纺车上谈论如何设计"架构"，这使我很伤心。我们想花费时间解决业务问题，而不是解决其他人为我们解决的问题。使用ORM(实际上并没有关系，只选择一个并坚持下去)可以获得最初的关注，这将有助于我们专注于项目目标，而不会分散我们尝试解决"体系结构"问题的注意力。

如果最终，架构师希望采用一种项目方法，则没有理由现在无法使用BLL和DAL文件夹创建app_code文件夹以分隔代码，这将转移到稍后进行N层解决方案。

回答

就像任何抽象都会造成复杂性一样，因此应该适当地证明进行N层级的复杂性是合理的，例如N层级实际上对系统有利吗？将有小型系统最适合与N层配合使用，尽管其中许多系统并非如此。

另外，即使系统目前很小，我们可能以后还要添加更多功能-不进行N层级划分可能会给我们造成一定的技术负担，因此我们必须小心。

回答

因为我们希望能够将层分布到不同的物理层上(我总是将"层"用于物理层，将"层"用于逻辑层)，所以在将所有内容归为一类之前，我们应该三思而后行。需要或者需要时开始分发时进行的主要重构。

回答

唯一的缺点是复杂性，但是与使用数据集相比，添加一些域对象并绑定到其中的列表实际上有多困难。我们甚至不必创建三个单独的项目，只需在Web应用程序中创建3个单独的文件夹，然后为每个文件夹指定一个名称空间，例如YourCompany.YourApp.Domain，YourCompany.YourApp.Data等。

最大的优势是拥有更灵活的解决方案。如果我们开始将应用程序编写为以数据为中心的应用程序，并将Web表单页面与数据集紧密耦合在一起，那么随着业务逻辑的复杂性不断提高，最终我们将不得不做更多的工作，后来又迁移到以域为中心的模型中。

也许短期内我们将重点放在一个简单的解决方案上，即创建非常简单的域对象并从数据集中填充它们，然后可以根据需要向它们添加业务逻辑并根据需要构建更复杂的ORM，或者使用nhibernate。