我在 dotnet 中使用分层架构（我主要从事 Web 项目）。我很困惑我应该使用哪些层？
我有个小想法，应该有以下几层。
我的目的是确保工作质量和代码的最大可重用性。
有人建议在其中添加通用类型层。请指导我应该是什么层？每一层应该去哪一部分？
【问题讨论】：
标签： c# .net asp.net architecture oop
对 Web 应用程序进行分层有点棘手。很多操作只是通过业务层，所以你往往会觉得它很没用。
分层的主要目的之一是使用户界面与数据存储隔离。理论上，您应该能够更改数据存储解决方案，而无需对用户界面进行任何更改。以我的经验，这种情况很少发生，但仅仅拥有抽象会给您带来其他优势，例如防止数据存储中的细节出现在用户界面设计中。
通常使用三层：
数据类/实体不是它们自己的层，而是层之间接口的一部分。通常，它们由业务层公开以供用户界面使用。
【讨论】：
这取决于您使用的数据访问技术。
如果您使用 NHibernate，我强烈推荐 Repository-pattern 以及一些依赖注入。
如果您使用的是 Linq-to-sql，则应该使用 Active Data Record-pattern。在这种情况下，你可能会也可能不会使用依赖注入。
在实体框架的情况下，可以使用工作单元模式。
通常我安排我的 VS2005/2008 - 解决方案如下：
而且，我这样安排我的代码：
namespace MySolution.Entity
{
public interface IMyInterface
{
int Save(MyClass obj);
}
}
namespace MySolution.Entity
{
public class MyClass
{
IMyInterface _myDa;
public MyClass(IMyInterface myDa)
{
_myDa = myDa;
}
private string _message;
public string Message
{
get { return _message; }
set { _message = value; }
}
public int Save()
{
return _myDa.Save(this);
}
}
}
using MySolution.Entity;
namespace MySolution.Service
{
public class MyClassService : IMyInterface
{
public int Save(MyClass obj)
{
Console.WriteLine(obj.Message);
return 1;
}
}
}
using MySolution.Entity;
using MySolution.Service;
namespace MySolution.UI
{
class Program
{
static void Main(string[] args)
{
MyClass myobj = new MyClass(new MyClassService());
myobj.Message = "Goodbye Circular Dependency!";
myobj.Save();
Console.ReadLine();
}
}
}
您可以将IMyInterface.cs 放在一个名为MySolution.Contracs 的单独项目中。并且，然后将它的引用添加到相应的程序集。
请注意，这称为分层设计，而不是分层设计。
您还可以为您的业务实体使用一个简单的框架，例如此 example 中使用的框架。
最后在您的 Winforms UI 层中使用 MVC 模式。您可以获取示例here。
而且我没有提供任何 ASP.NET MVC 的链接，因为网上有很多。
【讨论】：
这完全取决于需求，尤其是非功能性需求。
单用户交互式应用程序的答案可能与需要扩展以支持数千名用户的 Web 应用程序大不相同。
一般是 KISS，但要避免在整个代码中进行硬编码依赖。设计（单元）可测试性是一个很好的起点。
如果你没有好的直接答案，也许答案不是很重要（即不要过度设计和 YAGTNI）。
【讨论】：
我建议您首先查看 DDD (Evans) 和 Fowler 的应用程序模式。这将向您展示大局。您在项目中拥有的层数可能会有所不同：可以是 3 层或 5 层。这取决于项目的复杂性、您的经验等。所以没有明确的答案应该是多少层。层的主要目的是职责分离：表示层负责 UI 和 UI 逻辑，领域模型层负责您的业务逻辑，数据访问负责对您的对象进行 CRUD 操作等等。
【讨论】：