最佳中小型应用架构

Question

我正在开发一个中型应用程序并想实现应用程序架构，我已经阅读了一些架构书籍和方法并考虑

微软提出的 AAFN (Application Architecture For .net)

SOA

SDLM

SDO

MVC

反之亦然...

这是一个 Web 应用程序，可以与其他一些小型应用程序一起扩展（想想像一个（或两个）核心的 M.I.S 之类的东西）

我应该考虑哪些项目

通用 // 在所有项目中使用

框架 // 主框架

DAO // 数据访问对象（entityframework 或 nHibernate）

UI // 将提供 2 个变体 web 和 windows(wpf) 界面 )

BusinessEntities // 所有 subApplication 项目逻辑都会去那里

ApplicationNameProject // each application have their Own Logic (in BussinessEntities)

ApplicationUnit // 每个应用实体都会放在这里

ApplicationNameProject  // each application data Entity (in Application Unit)

Services // WCF 服务在这里为所有应用程序做出贡献

这是我想到的架构女巫，我没有任何力气用这个，我想知道什么最适合我，可以全部更改或添加一些其他项目并删除这些项目

任何帮助appriciated

Answer 1

没有“最佳的中小型应用程序架构”可以作为适合任何项目的灵丹妙药，因此请立即放弃这个想法，否则您将陷入痛苦的世界。

任何给定项目的架构都适合该项目的目的。在某些情况下，直接查询数据库的 ASP.NET WebForms 将是最合适的架构，在某些情况下，MVC 将是正确的架构，在某些情况下，构建在 Web 服务之上的 Windows 窗体应用程序连接到通过像 LINQ-to-SQL 或 NHibernate 这样的 ORM 的关系数据库。

您无法决定采用一种适用于所有架构的方法，它只是行不通。每种架构都有其优点和弱点，因此有适合的项目和应该避免的项目。您应该选择对当前项目/场景最有意义的方法。

但是，鉴于此，我倾向于采用相当统一的方法。

如果我需要一个快速实用的项目来做非常具体的事情并且极不可能用于其他任何事情，我可能会使用控制台应用程序来对我的数据库进行硬编码的查询。

如果我需要一组我可能需要来自多个项目的通用查询，我会将它们编写为存储过程以获得性能优势并构建一个数据访问层，该层将利用这些存储过程为我提供标准化业务对象，采用标准 DAL（数据访问层）/BOL（业务对象层）/BLL（业务逻辑层）方法。这是有利的，因为这意味着一旦我构建了这组库，我就可以将任何应用程序浮动到顶部——例如 webforms 或 MVC 应用程序。

MVC 的优势在于关注点分离 - 您的控制器可以与您的业务库交互，只是为了访问它需要的数据，而您的视图实际上就是这样 - 用户可以与之交互的数据视图。视图只是将当前数据视图提供给用户并将任何数据更改从用户传输回控制器 - 视图中不保存任何逻辑，因此这意味着单元测试和更改要容易得多组件而不影响应用程序的其余部分。

这样的多层或多层方法的缺点是，它需要时间来正确地构建它，如果你只是在使用像他们在开发者大会的舞台上展示的一次性实用应用程序，那么这个完全是矫枉过正，我不会打扰它。

这样想：每个层、每个库、每个组件都需要证明。如果支持的理由少于反对的理由，那就不要这样做。关键是不要无缘无故地做某事——只要你有一个深思熟虑的理由，你所做的任何事情都是正确的，而深思熟虑的意思是你已经找到了很好的理由赞成和反对，你已经做出了一个有根据的决定，你还没有根据一半的想法做出决定，或者更糟糕的是，根本没有考虑。

Answer 2

除了最琐碎的 .NET 应用程序之外，任何东西都应该有几个项目：一个 UI 层、某种业务逻辑层、一个持久性（存储）层和附带的测试项目。每个项目都应该通过接口松散地交互。

一般而言，您应该创建使代码可测试且易于理解所需的最少层数。

要弄清楚您需要的最低限度是多少，最好让您的测试驱动系统的内部设计。每个层都应该有自己的测试，（可能）除了顶层 HTML 层和底层 SQL 层。

考虑到这一点，它有助于尽可能分离关注点。例如，SQL 查询几乎不应该在与 HTML 支持相同的代码块中：将事物分成多个层，每个层只做一件事。这使更改更容易。

注意系统架构（使用 REST 等松散耦合的 Web 服务进行交互）和系统内部设计之间的区别。将 Web 服务接口（作为消费者或提供者）解耦到它们自己的层中是个好主意，因为这是一个经常变化的领域。

这些设计是最好通过实践学习的艺术。通过良好的单元测试，您应该会发现重构应用程序设计相当迅速，因此最好查看 Spring.NET 或其他控制容器反转等技术来简化此操作。