标签: three-tier

MVC和3层架构的基本区别是什么？

3层架构和mvc有什么区别？

它们一样吗？

两者都有3层,即模型,视图和控制器

我想知道Microsoft.Practices.EnterpriseLibrary.Data我们使用这个dll 是什么以及为什么.这个dll有什么好处.

我想在3层架构上创建一个项目,这是sql查询的最佳方式.

天气我使用这个DLL或去简单的sqlcommand和dataadapter.目前我正在以这种方式工作:我在DAL文件中的代码是:

public void Insert(long id)
{
    connection.Open();
    SqlCommand dCmd = new SqlCommand("test_procedure", connection);
    dCmd.CommandType = CommandType.StoredProcedure;
    try
    {
        dCmd.Parameters.AddWithValue("@id", id);           
        dCmd.ExecuteNonQuery();
    }
    catch
    {
        throw;
    }
    finally
    {
        dCmd.Dispose();
        connection.Close();
        connection.Dispose();
    }
}

我很困惑天气我正在以正确的方式工作,或者我应该使用Microsoft.Practices.EnterpriseLibrary.Data然后我创建DatabaseFactory.

它被认为是很好的做法,对于应用程序的每个层(即一个例外PresentationException,ServiceException,PersistenceException等).但是,如果我的服务层直接调用DAO方法(持久层方法)而没有额外的操作,那该怎么办呢？

像这样:

public class MyService {
   private IPersonDAO dao = new PersonDAO();

   public void deletePerson(int id) { 
      dao.deletePerson(id);
   }

}

我应该用try-catch块包装此DAO方法调用并重新抛出可能的异常ServiceException吗？每个DAO方法应该只抛出PersistenceException吗？

每次我开始处理新的ASP.NET MVC Web应用程序时,我都不确定是否使用DataAnnotations验证.关于它的事情感觉不对.

例如,假设我有UserService一个CreateUserModel从Create动作传递的AccountController.为确保用户始终提供名称,我将模型的Name属性设置为具有该[Required]属性.我现在安全地知道模型活页夹CreateUserModel除非有名字,否则不会给我一个.

我的问题是,为了UserService成为我系统的可重用组件,它不能依赖上面的层提供有效数据的事实,当然还必须验证这些数据.当您考虑要编写完全重用UserService(并且不会使用模型绑定器对其进行所有数据注释验证)的Web服务时,对此的需求会进一步突出显示.

所以我的问题是:这种情况的最佳做法是什么？使用数据注释进行验证并在服务中重复该验证？仅在服务中验证并抛出异常？两者兼而有之？

我希望我的问题不是太主观,我主要是试图就是否最终将验证转移到数据注释上达成共识.

试图实现3层(不是:层,我只是想在逻辑上将我的项目分开,在一台机器上)架构我发现了很多不同的方法,我很困惑,最好的方法是什么(如果有的话)在WinForms应用程序中.

现在我毫不怀疑项目中应该存在的3个层次:

• UI(表示层)
• BLL(业务逻辑层)
• DAL(数据访问层)

在UI中我放了所有的WinForms.必须还有一些逻辑用控件中的数据填充对象并将其传递给BLL层.

在DAL中,我想使用ADO.NET为数据操作添加类和方法,如:

public class OrderDAL
{
    public OrderDAL()
    {
    }

    public int Add(Order order)
    {
        //...add order to database
    }

    public int Update(Order order)
    {
        //...update order in database
    }

    //...etc.
}

问题在于BLL和问题 - 我应该使用数据传输对象在层之间传递数据,还是应该通过整个类？

如果我选择使用DTO,那么我将创建额外的公共类Order,即对UI,BLL和DAL的引用:

public class Order
{
    public int Id { get; set; }
    public DateTime Date { get; set; }
    public string Number { get; set; }
    public string CustomerName { …

想知道在多层应用程序结构中设置默认值的最佳方法。具体来说，如果某个工作流程需要一组嵌套的函数调用，那么默认值是在所有函数上指定，还是仅在顶层函数上指定并向下传递？或者完全是其他模式？

例如，考虑一个具有 3 层的 Web 应用程序：

• 资源层处理HTTP请求和响应，从客户端获取HTTP参数
• 业务层执行确定需要什么信息所需的业务逻辑
• 数据层访问数据库并返回所请求的数据。

假设客户端想要获取一个对象——对于这个例子，假设它是一个Place对象。地点对象有type——城市、州、城镇、县等。

资源函数可能如下所示（使用 Django HTTP 对象）：

def resource_get_place(request, type=None):
    """ Gets a place of the specified type, or a place of any type if
     type is None """

   place = business_get_place(type=type)

   return HttpResponse(request, {
       "place" : place
   }

那么另外两个可能是：

def business_get_place(type):
    # Trivial in this case, used for consistency
    return data_get_place(type)

def data_get_place(type):
    # Get a place of specified type from the cache, or db,
    # …

我有一个三层应用程序

DAL具有EDMX文件，EF6会由EF6自动从数据库生成（DB First模式）。我也有BLL和UL层。

但是，当我想在UI中使用BLL方法时，必须将DAL程序集添加到UI层（由于方法的返回类型）

List<Person> 

EDMX（DAL）中的人定义] （这是我的问题）

如何将类（DTO）与EDMX文件分开，并创建为单独的程序集？

如何防止将DAL程序集（整个EDMX）添加到UI层？

我正在编写一个设计文档,我的团队中的人员愿意从ASP.NET WebForm迁移到ASP.NET MVC.这很棒,但我很难理解MVC如何在3层(数据层,业务层和表示层)架构中工作.我们可以说模型,视图和控制器是表示层的一部分吗？模型是业务层的一部分吗？

简而言之,MVC和3层架构如何协同工作？谢谢您的帮助!

将DTO对象传递给服务层不是坏习惯吗？

现在，我的服务层方法如下所示：

public save(MyEntity entity);

从DTO到业务实体（MyEntity）的值映射在表示层上完成

但是我想将方法​​签名更改为此：

public save(MyEntityDTO dto, String author);

从DTO到业务实体的映射将在服务层上进行。

编辑：我想要它，因为从DTO映射到业务对象时需要打开休眠会话，因此实体上的所有更改都将自动刷新。