n-tier-architecture

问题 There are so many tutorials that teach us to use for example some ORM directly with database, but in real life i cant remember a big project that was working directly with database and not with services, so the amount of that tutorials seems strange to me. Directly connected applications have real benefits in speed of data transitions between database and the app, and they do not have restrictions in functionality that appear because of service layers(for example lets take Entity framework

问题 I have an N-Layer application as shown below MyApp.Model - contains edmx and data models MyApp.DataAccess - Repositories with EF MyApp.Domain - Domain/business models MyApp.Services - services(class library) MyApp.Api - ASP.NET Web API I am using Unity as my IoC container and Automapper for OO mapping. My DataAccess layer references Model layer which contains all my Data objects. I do not want to refer my model project in my Api layer. So returning DomainObjects (business models) from service

问题 What is the best way and why? V1: try { var service = IoC.Resolve<IMyBLService>(); service.Do(); } catch(BLException ex) { //Handle Exception } V2: var service = IoC.Resolve<IMyBLService>(); var result = service.Do(); if (!result.Success) { //Handle exception } 回答1: Exceptions are better in my opinion. I think that DDD code is first and foremost good object oriented code. And the debate about using exceptions vs return codes in OO languages is mostly over. In DDD context I see following

问题 Does Dependency Injection violate the Separation of Concerns as it pertains to an n-tier architecture? Suppose you have the following projects: MyApp.Data MyApp.Business MyApp.Web If I were to use DI to tell the Business Layer which Data Context to use, wouldn't this violate SoC? This would mean the UI (MyApp.Web) would have to have knowledge of the Data Access Layer (MyApp.Data) to tell the Business Layer (MyApp.Business) which context to use, right? public class WebForm { public void Save

问题 Does Dependency Injection violate the Separation of Concerns as it pertains to an n-tier architecture? Suppose you have the following projects: MyApp.Data MyApp.Business MyApp.Web If I were to use DI to tell the Business Layer which Data Context to use, wouldn't this violate SoC? This would mean the UI (MyApp.Web) would have to have knowledge of the Data Access Layer (MyApp.Data) to tell the Business Layer (MyApp.Business) which context to use, right? public class WebForm { public void Save

问题 I realize there have already been a number of posts on n-tier design and this could possibly be me over thinking things and going round in circles, but I have myself all confused now and would like to get some clarity from the community please. I am trying to separate a project I created, (and didn't design architecturally very well to start with), out into different layers (each in their own project): UI Business Objects Logic / Business DAL The UI should only call the Logic layer to get its

问题 Background I'm trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repository classes at runtime. This keeps my Domain and Application Services layers testable. I plan on using "poor man's DI" to accomplish this for now ... so I would do this in a simple Console application near startup: // Poor man's DI, injecting DAL repository classes at runtime var productRepository = new SimpleOrder.Repository

问题 Background I'm trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repository classes at runtime. This keeps my Domain and Application Services layers testable. I plan on using "poor man's DI" to accomplish this for now ... so I would do this in a simple Console application near startup: // Poor man's DI, injecting DAL repository classes at runtime var productRepository = new SimpleOrder.Repository

问题 I am working on e-tier architecture within MVC framework (ASP.NET MVC5, Entity Framework 6). My application is divided into three sub-projects which are Business-Layer, Data-Access-Layer, Repository (This include repository and Unit of Work) and ASP.NET MVC web-app. I am struggling to understand mapping between business data and entity framework model. for example if I have model class User in entity framework as DAL - User Model [Table("User")] public class User { public User() { } [Key]

问题 I'm having an architectural decision-problem: We're about to build a new application and we've decided we'll be using ASP.NET MVC and Entity Framework (database first probably). In the first fases we'll only be building a web application for regular browsers, but in the future we might add mobile applications. (SOA?) My question is now what would be the best way to build up the application architecture? Would this be correct? MvcProject Model View Controller DAL project Holds edmx and T4