我正在开发一个中型应用程序并希望实现应用程序架构，我已经阅读了一些架构书籍和方法并且考虑了
由Microsoft提交的AAFN（针对.net的应用程序Arcitecture）
SOA
SDLM
SDO
MVC
反之亦然......
这是一个Web应用程序，它将与其他一些小应用程序一起扩展（只需考虑像带有（或两个）核心的M.I.S）
我应该考虑的Whitch项目
通用//在所有项目中使用
框架//主框架
DAO //数据访问对象（entityframework或nHibernate）
UI //将在2个变体网页和窗口（wpf）界面中提供
BusinessEntities //所有子应用程序项目逻辑都将在那里
ApplicationNameProject // each application have their Own Logic (in BussinessEntities)
ApplicationUnit //每个应用程序实体都会放在这里
ApplicationNameProject // each application data Entity (in Application Unit)
服务// WCF服务随时为所有应用程序做出贡献
这是我想到的架构女巫，我没有任何力量可以使用它，我想知道什么是最适合我的，可以改变所有这些或添加一些其他项目并删除这些项目
任何帮助appriciated
答案 0 :(得分：5)
没有“最佳的小型或中型应用程序架构”作为适合任何项目的灵丹妙药，所以现在就放弃这个想法，否则你将会陷入一个痛苦的世界。
任何给定项目的架构都符合该项目的目的。在某些情况下，直接查询数据库的ASP.NET WebForms将是最合适的架构，在某些情况下，MVC将是正确的架构，在某些情况下，Windows窗体应用程序构建在连接到a的Web服务之上。关系数据库通过ORM，如LINQ-to-SQL或NHibernate。
你无法决定采用一种架构适合所有方法，它只是不起作用。每个架构都有其优点和缺点，因此适合的项目和应该避免的项目。您应该选择对当前项目/场景最有意义的方法。
然而，鉴于此，我倾向于采取相当统一的方法。如果我需要一个快速的实用程序项目，该项目执行非常具体的操作并且不太可能需要其他任何东西，我可能会使用控制台应用程序对我的数据库进行硬编码查询。
如果我需要从多个项目中可能需要的一组通用查询，我会将它们编写为存储过程以获得性能优势并构建一个利用这些存储过程的数据访问层来给我标准化业务对象，在标准DAL（数据访问层）/ BOL（业务对象层）/ BLL（业务逻辑层）方法中。这是有利的，因为这意味着一旦我建立了这组库，我就可以将任何应用程序浮动到顶层 - 例如webforms或MVC应用程序。
MVC是有利的，因为关注点分离 - 您的控制器可以与您的业务库交互，只需访问所需的数据，您的视图就是这样 - 用户可以与之交互的数据视图。视图只是将当前数据视图传递给用户并将任何数据更改从用户传输回控制器 - 视图中没有逻辑，因此这意味着单元测试和更改更容易组件不会影响应用程序的其余部分。
像这样的多层或多层方法的缺点是需要时间来正确地构建它，如果你只是在他们在开发者大会的舞台上展示的丢弃实用程序应用之后那么这个是完全矫枉过正，我不打扰它。
这样想：每个层，每个库，每个组件都需要证明理由。如果没有理由比反对，那么就不要这样做。关键是不要没有理由做任何事情 - 你所做的任何事都是正确的，只要你有经过深思熟虑的理由，经过深思熟虑，我的意思是你找到了很好的理由赞成和反对，你做出了一个有根据的决定，你没有根据一半的想法作出决定，或者更糟糕的是，根本没有想到。
答案 1 :(得分：0)
除了最简单的.NET应用程序之外的任何东西都应该有几个项目：UI层，某种业务逻辑层，持久性（存储）层和附带的测试项目。每个项目都应该通过接口进行松散的交互。
通常，您应该创建所需的最少层数，以使您的代码易于理解且易于理解。
要弄清楚您需要的最小值，最好让测试驱动系统的内部设计。每个层都应该有自己的测试，（可能）除了顶层HTML层和底层SQL层之外。
考虑到这一点，它有助于尽可能地区分问题。例如，SQL查询几乎不应该与HTML支持位于同一代码块中：将事物分成多个层，每个层执行一个且只执行一个操作。这使得更改变得更容易。
请注意系统架构（使用例如REST交互的松散耦合的Web服务）与系统内部设计之间的区别。将Web服务接口（作为消费者或提供者）分离到他们自己的层中是个好主意，因为这是一个经常变化的区域。
这些设计是一种通过实践学到的最好的艺术。通过良好的单元测试，你会发现应用程序设计的重构非常迅速，所以最好先看看Spring.NET等技术或其他控制容器的反转，以便轻松实现。