我将开始说我没有使用实体框架或任何类型的ORM – 我想直接实现我自己的业务对象和数据访问代码(使用ADO,SPROCS等)来确保它们是最优的,这是一个个人喜好.这是我正在努力寻找一致的信息,因为它似乎大多数信息与使用LINQ to sql或实体框架有关.
我的申请结构如下：
> Web(MVC 3 Web应用程序)
>模型(类库)
只有两个项目,因为我有问题脱钩事情;这是我问题的根源.
我的模型类库包含…
>具有领域和属性的经典业务对象
>包含数据访问代码(ADO.NET直接sqlDataReaders等)的每个业务对象的存储库类
>每个存储库类的接口
我所遇到的问题是所有这些层之间的依赖关系.它根本不觉得对！
业务对象应该包含实现业务逻辑的方法,除了字段和属性之外,还有方法来实现任何所需的逻辑？
2.存储库类执行数据访问代码,但是了解业务对象,这再一次感觉不对,数据访问代码应该位于其自己的类库中,并且不了解对象？
控制器(在Web层中)利用存储库接口,但为什么？他们不应该包含业务逻辑,“模式”还是业务对象呢？控制器当然不应该包含业务逻辑,所以这是不对的.在数据库中,我不希望存储库中的业务逻辑.
我正在努力为应用程序找到一个优雅的架构,只是一个基本的概述,如何实现我自己的对象,我自己的数据访问代码,并确保应用程序松散耦合.任何人都可以提供任何指导吗？
解决方法
例如,项目的结构可以如下：
核心图书馆
这将是简单的POCO,代表您的域数据和任何服务的接口.这里没有商业逻辑.只是简单的属性.
例如.
公共类用户
{
public int UserId {get;组; }
public string Name {get;组; }
}
- Core
\Entities <-- Poco's
\Services <-- Interfaces for services
服务
这将是您包含业务逻辑的地方.用户如何验证？我们如何计算订单何时应该自动存档或什么？一般来说,我没有在这里做任何数据库的东西.
知识库
这是你做基本数据库的地方.你说你没有使用L2S或EF等.没有可能.我会认真地看着使用Micro-ORM,如Dapper或Massive.
测试
你在做单元和集成测试,对吧？我推荐用于测试框架的xUnit或nUnit.
Web应用程序
这是MVC3应用程序.我建议您使用StructureMap进行依赖注入. (您正在使用IoC / DI？)
你可以先考虑一下 – >这是很多项目的SOOO,对吧？那么很容易把它分成两个项目.
> Web应用程序
>测试项目
Core Library,Services,Repository都作为文件夹存在于Web应用程序项目中.
尝试并不要过度设计Visual Studio解决方案.大多数人认为他们需要大量的项目和抽象的负担,因为这是他们认为其他人正在做的事情,这是对的.那么这个思路是非常早的2000年代初的.而在2012年,很多shiz从此改变了.
尝试使用DI / IoJ,NuGet将这些库下载到您的解决方案中,Micro-OR / M用于数据访问和测试项目.
一些项目检查,重新：如何布局：
