我正在努力为我当前的项目获得一个好的架构。这是我第一次尝试使用软件工程的最佳实践(DI、单元测试等)来设计一个严肃的 n 层应用程序。我的项目使用的是洋葱架构。
我有4层
核心层:它持有我的业务对象。在这里,我有代表我的业务实体的类及其方法。其中一些对象具有对服务接口的引用。
DAL(数据访问)层:它定义 POCO 对象并实现核心层中定义的存储库接口。在这一层中,我认为设计一个大型实用程序类是一个好主意,其作用是将 POCO 对象从 DAL 转换为来自核心的业务对象。
服务层:它实现了核心中定义的服务接口。该层的作用是提供对 DAL 中定义的存储库的访问。我主要认为这个层没有用,所以我直接使用了核心层中定义的存储库接口。然而,在花了几个星期编写很长的实例化代码之后——让构造函数采用 5-6 个 IRepository 参数——我明白了服务层的意义。
表示层。这里没什么特别要说的,只是我在这个层中配置了依赖注入(我使用的是 Ninject )。
我已经更改了架构并至少重写了 3 次代码,因为很多时候我发现我的代码有问题。(例如带有长参数列表的长构造函数)。幸运的是,我对文献中发现的各种编码模式有所了解。
然而,我刚刚遇到了我的 DI 的周期性依赖,我很想知道我的 DAL2Core Helper 是否是个好主意......
感谢这个助手,我可以编写如下代码:
DAL.Point p = DAL2Core.PointConverter(point); // point is a Core Object
context.Points.Add(p);
context.SaveChanges();
这减少了一点代码冗余。然后我在 DAL 中定义的每个存储库都有自己的 DAL2Core 成员:
private IDAL2CoreHelper DAL2Core;
我从 Repository 构造函数注入它。
DAL2Core 类本身有点混乱……首先,它对每个存储库和每个处理器(服务层)都有一个属性。处理器存在的原因是我的核心对象需要注入处理器依赖项。我将我的 DAL2Core 实用程序类中引用的一些存储库和处理器放在下面只是为了说明:
[Inject]
private Core.IUserRepository UserRepository{ get; set; }
[Inject]
private Core.IPointsRepository PointsRepository { get; set; }
...
[Inject]
private Core.IUserProcessor UserProcessor{ get; set; }
[Inject]
private Core.IPointsProcessor CoursProcessor { get; set; }
(由于存储库需要 DAL2Core Helper,因此构造函数注入会导致循环依赖)
然后这个类有很多简单的方法,例如:
public Core.User UserConverter(DAL.User u)
{
Core.User user = new Core.User(UserProcessor);
user.FirstName= u.FirstName;
user.Name= u.Name;
user.ID = u.ID;
user.Phone= u.Phone;
user.Email= u.Email;
user.Birthday= u.Birthday;
user.Photo = u.Photo;
return user;
}
这个类就像60000行。想一想,我意识到我并没有节省太多代码,因为很多时候 DAL2Core 转换代码只从一个地方调用,所以也许最好将此代码留在存储库中?而且 - 最大的问题 - 因为我决定将此帮助程序与我的存储库类分离,所以 Ninject 会抛出周期性依赖异常。
您如何看待我尝试的设计,这是一种好的/常见的做法吗?以及我怎样才能巧妙而有效地执行此 DAL2Core 转换而不会产生代码异味。我真的很期待解决这个架构问题,过去三周我一直在处理管道和架构问题,并没有真正推进那个项目。我变得很晚了。但是我真的很想生成高质量的代码。我只是想避免对我来说看起来有点矫枉过正的架构解决方案,有很多工厂等......但我承认有时,这种感觉只是来自我缺乏理解(比如服务层)。
在此先感谢您的帮助 !