标签: n-layer

我有一个C#N层项目,有5个层:1个基础设施2个域3-AppService 4个分布式服务5个演示

我想在我的项目中使用枚举.但我不知道哪一层描述了它们.我有两个想法.

1-在域中声明枚举并通过WCF DataContract传递网络.

2-在类库项目中声明枚举(例如:在公共层中)并将其构建为dll并在所有层中使用它.

帮我选一个.

我有一个带有实体框架的N层应用程序(代码优先方法).现在我想自动化一些测试.我正在使用Moq框架.我发现编写测试有些问题.也许我的架构错了？如果错误,我的意思是我编写的组件不是很好,因此它们不可测试.我真的不喜欢这个......或许,我根本无法正确使用moq框架.

我让你看看我的架构:

在每个级别,我都会context在类的构造函数中注入.

门面:

public class PublicAreaFacade : IPublicAreaFacade, IDisposable
{
    private UnitOfWork _unitOfWork;

    public PublicAreaFacade(IDataContext context)
    {
        _unitOfWork = new UnitOfWork(context);
    }
}

BLL:

public abstract class BaseManager
{
    protected IDataContext Context;

    public BaseManager(IDataContext context)
    {
        this.Context = context;
    }
}

存储库:

public class Repository<TEntity>
    where TEntity : class
{
    internal PublicAreaContext _context;
    internal DbSet<TEntity> _dbSet;

    public Repository(IDataContext context)
    {
        this._context = context as PublicAreaContext;
    }
}

IDataContext 是一个由我的DbContext实现的接口:

public partial class PublicAreaContext : DbContext, …

我将开发一个相当大的winform项目.我打算使用Entity Framework作为ORM工具.现在我正在寻找一个架构(MVC/MVP/MVVM等......)来实现所有这些.首先,对于Windows窗体的n层架构几乎没有选择,我得到的大部分都是在EF进入市场之前编写的.我从codeplex获得了一个名为Rocket Framework的框架(http://rocketframework.codeplex.com)

我环顾了一下,但我怀疑它会满足各种各样的要求.如果有人已经发现了车轮,请指导我.此外,如果EF4之前的现有架构可以容纳它,我也可以尝试一下.好主意!

我正在制作一个基于 .Net 的应用程序的结构。目前，我使用的是 MVC 5。以下是系统不同组件的详细信息。\n
1. 数据库\xe2\x80\x93 这是底层数据库，将包含数据\n
2. OData API \xe2\x80\ x93 此 API 将与数据库交互，并且仅执行与数据库相关的操作 (CRUD)。我希望这个 API 成为访问和操作数据的唯一平台。它将提供通过不同方式（IQueryable、SQL 查询、存储过程）检索数据的功能。\n
3. 业务服务\xe2\x80\x93 它由两部分组成。引擎和API。引擎中将包含业务逻辑，其中可能包括业务规则，例如 WorkflowEngine 将处理所有工作流操作。驻留工作流程操作（CRUD 操作）和非常驻工作流程操作（提交、批准、发回）。API将在UI和引擎之间进行通信。然后引擎将运行业务逻辑并与 OData 进行通信。BusinessAPI 将是专有 API，对这些 API 的访问将基于订阅（付费访问）。\n
4. UI \xe2\x80\x93 用户界面将基于 MVC，仅与业务 API 交互，并且仅负责显示数据并将数据发送回 BusinessAPI。
\n

它看起来像一个 N 层架构。如果我引入接口，它是否可以与ONION架构相媲美。\n
如何将其转换为 ONION 架构而不影响安全性、可扩展性和性能。\n

我有一个用C#... .Net 4.0编写的4层Web应用程序:

• UI层
• 业务层
• 数据访问层
• 实体层

我的数据层包含一个edmx我的实体层包含我的POCO对象(由t4脚本生成),并且该层在所有其他层中引用.

例如,在创建MVC表单以创建新客户时....我已经在我的实体层中拥有了包含名字,姓氏等字段的客户类,但该自动生成的POCO类没有数据注释用于验证...提交表单时的IE [必需]等

我现在的解决方案是创建新的模型类,它与我的poco类几乎相同,但也有这些额外的验证注释.

我想知道的是,在MVC模型中(在UI层中)使用某些POCO对象是一种简单的方法,而不必几乎重写类...而且还没有修改生成这些POCO类的t4(因为我在t4上没有达到速度.

我在stackoverflow http://automapper.codeplex.com/上的另一篇文章中看到了这个...不确定这是否会这样做或者是最好的解决方案.

N层架构有哪些好处？这如何使应用程序更好？

我有一个关于n层架构的问题.在问这个问题之前,我想了很久很久,因为这里已经有很多类似的问题......然而,经过一天半的时间看着它并阅读其他答案后,我仍然不确定.各种看似相似的术语和不同的方法令我感到困惑.

如果我在不同的类库中有一个BLL和一个DAL,BLL和DAL之间进行通信的一种方法是利用一个接口,有点像在另一个由BLL和DAL引用的单独DLL中定义的DTO.我在BLL中的域模型实体将实现此接口,因此DAL中的任何ORM生成对象也将实现此接口.为了保存我的业务实体,我可以将它们传递给DAL,它可以接受它们,因为它们实现了共享接口.我还可以将对象传递回实现此接口的BLL.这似乎是合理的,因为BLL和DAL只需要知道基本接口,而不是每个其他具体实现.

我的问题是在另一边创建对象的最佳方法是什么？例如,如果我在BLL中实现了一个实现IPerson的Person对象,以及一个PersonDataObject或同样实现IPerson的DLL中的任何东西,我将Person传递给DAL中的一个方法,该方法接受IPerson的参数,然后在DAL I'中d必须重建PersonDataObject才能持久化.这甚至是最好的方法吗？

对不起,我可能没有解释得太好,因为我很困惑.对于假人答案的最佳做法将非常感激.

在以下示例中,AccountService和ProductService位于ASP.NET MVC应用程序中.该AccountWebAPI和ProductWebAPI是外部托管API的微服务.

1)我可以消除ProductService并协调检索CustomerAccountController本身的订单吗？这是因为我将Controller视为DDD(域驱动设计)中提到的应用层/服务.

2)我是否违反了n层架构,因为ProductService调用的AccountService是同一层？

3)由于AccountWebAPI和ProductWebAPI是微服务,它们是否必须在客户端应用程序(MVC App)中作为AccountService和ProductService分开,以保持责任分离？因此,ProductService需要重命名为ProductAppService,ProductService应该与ProductWebAPI交互,就像AccountService与AccountWebAPI的对话一样.

public class CustomerAccountController : Controller 
{ 
    IProductService _productService;

    public CustomerAccountController(IProductService productService)
    {
        _productService = productService;
    }

    public IActionResult Index()
    {
        return View();
    }

    public IActionResult Account(int customerId)
    {
        var orders …