Question

我正在使用WCF，实体框架和POCO的服务器层类构建N层应用程序，而对于客户端，我正在使用带有MVVM模式的WPF。服务器端代码我将其分为4个项目：

* Data Layer(DAL -> EF)
* Model Layer (POCO's classes)
* Business Layer (BAL)
* Service Layer (WCF)

对于所有服务器层和wcf客户端之间的通信，我在模型和接口上定义，我在每个层上实现。我将自己编写所有代码，从DAL到表示层，因此需要分离关注但不是必需的。

所以我的问题：

1）这个设计是否适合自己作为所有代码的作者？

2）为了简单起见，我应该减少项目的数量吗？

3）在每一层上实现一个接口是个好主意吗？因为我发现自己必须为每种新方法编写非常相似的代码3次。像这样：

在WCF服务上：

public IEnumerable<Clientes> GetClients()
    {
        BusinessLayer.Ohmio _cli = new BusinessLayer.Ohmio();
        return _cli.GetClients();
    }

关于商业：

public IEnumerable<Clientes> GetClients()
    {
        DataLayer.Ohmio bn = new DataLayer.Ohmio();
        return bn.GetClients();
    }

关于数据：

public IEnumerable<Clientes> GetClients()
    {
        using (var context = new OhmioEntities())
        {
            var _clients= context.Clientes.ToList();                
            return _clients;
        }
    }

接口方法还有两个问题：

1）我对comunícate服务器端层和wcf客户端使用相同的接口，因此数据类型必须相同。

2）对于复杂的应用程序（如我正在构建的那个），接口和所有实现的类将是巨大的！因为他们需要我项目中所有对象的所有方法！

这类病例有更好的解决方案吗？任何建议将被认真考虑！！！！谢谢！

Answer 1

接口和抽象构建了依赖注入（控制反转）的基础，允许独立地测试组件和层。像你一样有单独的层建议帮助分离关注点，降低复杂性，提高可测试性，可维护性等。

对于小型和简单的应用程序，这种努力可能不值得。但是，越大和复杂的应用程序越多，将最佳实践和设计原则和模式考虑在内就越重要。

为了避免使用所有图层设置解决方案并编写所有锅炉电镀代码的努力，您可能有兴趣尝试 N-Tier Entity Framework 这是一个开源框架与您描述的场景完美匹配。在任何情况下，您都应该查看其documentation，其中包含有助于您设计此类解决方案的体系结构注意事项的专用部分。

使用WCF服务的NTier设计建议

1 个答案: