如何扎实，组织架构应该是什么？ [英] How a solid and organized architecture should be?

问题描述

在工作中我们将要重新编写一个旧的应用程序，我被告知让我们如何能做到这一点的一些想法。

At work we're about to re-write an old application and I was told to get some ideas about how we could do it.

我的想法是这样的：

由于应用程序将主要网站我会使用MVC。 EF与POCO实体DI和IOC。 WCF为Web应用程序和其他客户端将消耗的服务。

Since the application will be mainly a website I'd use MVC. EF with POCO entities for DI and IoC. WCF for the services that the web app and other clients will be consuming.

到目前为止，架构应该是这样的：
  - Demo.Web
  - Demo.Entities
  - Demo.Services

So far the architecture should look like this: - Demo.Web - Demo.Entities - Demo.Services

现在我的架构是这样的：

Now my architecture looks like this:

空间Demo.Entities

// IEntity.cs
public interface IEntity { }

//User.cs
public virtual long UserId { get; private set; }
public virtual string Name { get; private set; }

public User() { }
public User(long userId, string name)
{
    UserId = userId;
    Name = name;
}

空间Demo.Services

// IService.cs
public interface IService<T> : IDisposable where T : IEntity
{
    List<T> GetList();
}

// UserService.cs
public class UserService : IService<User>
{
    public List<User> GetList()
    {
        return new List<User>(); // Simplicity
    }

    public void Dispose() { }
}

当我需要用这个，我会做：

using(IService<User> service = new UserService())
{
    var q = service.GetList();
}

至于MVC的，我会用模型从Demo.Models，如果需要有实际的模型，我将其链接到我的模式我的MVC应用程序的文件夹中，但现在MVC是我的最后一个问题。

As for MVC, I will use the models from Demo.Models, and if need to have the actual models I will link them to my Models folder of my MVC application, but now MVC is my last concern.

到目前为止，我发现一个问题，我将无法查询多个实体没有实例指定的服务。在光明的一面我有什么和如何我的数据被处理的完全控制。

So far I've detected one issue, I won't be able to query multiple entities without instantiating the specified service. On the bright side I have full control of what and how my data is being handled.

实际问题

如果有，任何人都可以点我的建筑设计，以支持这些功能？

If any, can anyone point me to any architectural design to support these features?

推荐答案

我所描述的稳固的架构原则的忠实粉丝的这里和这里。你做出最后决定之前，他们是值得检查和扣球。 DotNetJunkie也将发布有关如何使用WCF的某个时候在不太遥远的将来使用这些模式的另一个博客条目。他描述了接口和模式去耦足以与任何EF或NHibernate的使用它们。

I am a big fan of the SOLID architecture principles described here and here. They are worth checking out and spiking before you make a final decision. DotNetJunkie will also be posting another blog entry about how to use these patterns with WCF sometime in the not-too-distant future. The interfaces and patterns he describes are decoupled enough to use them with either EF or NHibernate.

一个关注我的帖子看到的是IEntity接口。我不认为你需要有一个接口，用于你的基地entitiy，通常是一个抽象基类是足够的（即使用层超类型的模式）。我从来没有发现一个理由让所有实体订阅一个单一的界面合同。

One concern I see with your post is the IEntity interface. I don't think you need to have an interface for your base entitiy, usually an abstract base class is enough (i.e. using the Layer Supertype pattern). I have never found a reason to make all entities subscribe to a single interface contract.

我还没有看到你的例子任何依赖注入。使用使用任何code（IService＆lt;使用者＆GT; CTX =新UserService（））走的是接口和实现上的依赖。您希望您的MVC或其他客户端code到只需要在接口上的硬盘的依赖，并有具体的实现解决了/你的控制容器的反转注入。这是href=\"https://stackoverflow.com/a/11902274/304832\">的trailmax洋葱架构发布关于是在

I also don't see any dependency injection in your examples. Any code that uses using(IService<User> ctx = new UserService()) is taking a dependency on the interface AND the implementation. You want your MVC or other client code to take a hard dependency only on the interface, and have concrete implementations resolved/injected by your inversion of control container. This is a pattern that is common in the Onion Architecture that trailmax posted about.

我不喜欢你有一个项目的三足鼎立的想法。尽量不要让解决方案中的项目数量得到比约5个项目虽然较大（不包括单元测试项目中，那些不计）。

I do like your idea of having a "tripod" of projects. Try not to let the project count in your solution get bigger than about 5 projects though (excluding unit test projects, those don't count).

到目前为止，我发现一个问题，我将无法查询多个
  实体没有实例指定的服务。光明
  一边，我有什么和如何我的数据被处理的完全控制。

So far I've detected one issue, I won't be able to query multiple entities without instantiating the specified service. On the bright side I have full control of what and how my data is being handled.

同样这些问题可以通过阅读并采用能够处理的 ICommandHandler 和 IQueryHandler / 在我上面提到的文章中所描述IQueryProcessor ​​模式。您不必在所有实例化的服务。你只需构造函数注入或者 IQueryProcessor ​​或 ICommandHandler＆LT; TCommand＆GT; 到控制器，让IoC容器提供实现。如果您有需要查询多个实体的操作，你只要做到这一点通过访问任何EF或NHibernate的查询的处理方法。

Again these concerns can be handled by reading and adopting the ICommandHandler and IQueryHandler / IQueryProcessor patterns described in the articles I mentioned above. You do not have to instantiate any services at all. You just constructor-inject either IQueryProcessor or ICommandHandler<TCommand> into your controller, and let the IoC container provide the implementation. If you have an operation that needs to query multiple entities, you just do that by accessing either EF or NHibernate in your query's Handle method.

下面是我的项目之一的一个例子，它使用这些模式

Here is an example of one of my projects that uses these patterns:

MyApp.Domain.csproj

这包含了所有实体以及在DotNetJunkie接口，命令+查询实现类库。这需要的不依赖的对实体框架或其他任何项目。

Class library that contains all entities as well as the DotNetJunkie interfaces, and command + query implementations. This takes no dependencies on Entity Framework or any of the other projects.

MyApp.Impl.csproj

类库包含的接口的实现，以及EF的DbContext和IoC容器。这需要依赖于域项目以及EF，国际奥委会图书馆等。

Class library that contains implementations of interfaces, as well as the EF DbContext and the IoC container. This takes dependencies on the Domain project as well as EF, the IoC library, etc.

MyApp.Mvc.csproj

该MVC项目需要依赖于其他两个。

The MVC project takes dependencies on the other two.

这是洋葱架构的一个非常基本的例子。

This is a very basic example of the Onion Architecture.

这篇关于如何扎实，组织架构应该是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！