最佳中小型应用Arcitecture

Question

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

AAFN(应用Arcitecture For .net)由Microsoft提供

SOA

SDLM

SDO

MVC

反之亦然......

这是一个Web应用程序,将与其他一些小应用程序一起扩展(只需考虑类似具有(或两个)核心的MIS)

我应该考虑的Whitch项目

常见//在所有项目中使用

框架//主框架

DAO //数据访问对象(entityframework或nHibernate)

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

BusinessEntities //所有子应用程序项目逻辑都将在那里

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

ApplicationUnit //每个应用程序实体都将放在此处

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

服务// WCF服务随时为所有应用程序做出贡献

这是我想到的架构女巫,我没有任何力量可以使用它,我想知道什么是最适合我的,可以改变所有这些或添加一些其他项目并删除这些项目

任何帮助appriciated

Answer 1

没有"最好的小型或中型应用程序架构"作为适合任何项目的银弹,所以现在放弃这个想法,否则你将陷入一个痛苦的世界.

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

你不能决定采用一种架构适合所有的方法,它只是不起作用.每个架构都有其优点和缺点,因此适合的项目和应该避免的项目.您应该选择对当前项目/场景最有意义的方法.

但鉴于此,我倾向于采取相当统一的方法.

如果我需要一个快速的实用程序项目来完成一个非常具体的事情而且其他任何事情都不太可能需要,我可能会使用一个控制台应用程序来查询我的数据库硬编码.

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

MVC是有利的,因为关注点分离 - 您的控制器可以与您的业务库交互,只需访问所需的数据,您的视图就是这样 - 用户可以与之交互的数据视图.视图只是将当前数据视图传递给用户并将任何数据更改从用户传输回控制器 - 视图中没有逻辑,因此这意味着单元测试和更改更容易组件不会影响应用程序的其余部分.

这样的多层或多层方法的缺点是需要时间来正确地构建它,如果你只是在他们在开发者大会的舞台上演示的丢弃实用程序应用之后那么这就是完全矫枉过正我不打扰它.

可以这样想:每个层,每个库,每个组件都需要证明.如果没有理由比反对,那么就不要这样做.关键是不要没有理由做任何事情 - 你所做的任何事情都是正确的,只要你有充分考虑的理由,经过深思熟虑,我的意思是你找到了很好的理由支持和反对你做出了一个有根据的决定,你没有根据一半的想法作出决定,或者更糟糕的是,没有任何想法.