我在dotnet中使用分层架构(主要是我在Web项目上工作)。我很困惑我应该使用哪些图层?
我不知道应该有以下几层。
我的目的是确保工作质量和代码的最大可重用性。
有人建议在其中添加常见类型图层。请指导我应该分层?在每一层中应该去哪一部分?
答案 0 :(得分:2)
分层Web应用程序有点棘手。很多操作只是通过业务层,因此你会觉得它很无用。
分层的主要目的之一是使用户界面与数据存储隔离。理论上,您应该能够更改数据存储解决方案,而无需对用户界面进行任何更改。根据我的经验,这种情况很少发生,但只是抽象提供了其他优势,例如保持数据存储中的细节不会出现在用户界面设计中。
通常使用三层:
数据类/实体不是它们自己的层,而是层之间的接口的一部分。通常,它们由业务层公开以供用户界面使用。
答案 1 :(得分:1)
这一切都取决于要求,特别是非功能性要求。
单个用户交互式应用程序的答案可能与需要扩展以支持数千名用户的Web应用程序非常不同。
一般来说KISS,但要避免整个代码中的硬编码依赖。设计(单元)可测试性是一个很好的起点。
如果你没有立竿见影的答案,也许答案不是很重要(即不要过度工程,而且不要过YAGTNI)。
答案 2 :(得分:1)
我建议你首先看看DDD(Evans)和Fowler的app模式。这将向您展示大局。项目中的层数可能有所不同:它可以是3或5。这取决于项目的复杂程度,经验等。所以没有明确的答案应该有多少层。层的主要目的是分离职责:表示层负责UI和UI逻辑,域模型层负责您的业务逻辑,数据访问负责对象的CRUD操作等等。
答案 3 :(得分:1)
这取决于您使用的数据访问技术。
如果您正在使用NHibernate,我强烈建议使用Repository-pattern以及一些依赖注入。
如果您使用的是Linq-to-sql,则应该使用Active Data Record-pattern。在这种情况下,您可能会也可能不会使用依赖注入。
如果是Entity Framework,可以使用工作单元模式。
一般来说,我会安排我的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提供任何链接,因为网络中有很多。