处理开发需要在多种查看模式（即桌面和移动/ iphone）中实现的Web应用程序的常见做法是什么？使用多种查看模式管理Web应用程序项目
为每种模式开发多个应用程序或尝试将所有代码保留在同一应用程序中更好吗？如果所有的页面功能都是相同的（即有时移动版本不能“做”他们的网页对应的功能），它会有所作为吗？什么是一些标准来决定是否将应用分成多个项目，陷阱等？是否有任何特定的架构模式可以让工作更轻松？
在我看来，除非应用程序可以简单地在不同的视图中呈现，否则最好为每个应用程序创建一个单独的应用程序。
假设应用程序类似于Gmail或Facebook（具有多种功能的大型应用程序），而不是简单的hello世界类型或静态企业网站。
我目前正在使用Grails进行开发，但这可能适用于多个框架。
您应该将后端构建为Web服务。这意味着任何UI都可以与服务进行交互，并且呈现逻辑与业务逻辑分开。
对于Microsoft平台，ASP.NET MVC或ADO.NET数据服务在这里是很好的选择。表示层应该完全分离到不同的项目中，以确保它独立于业务逻辑。
但是，在使用RESTful方法的其他平台中执行它应该同样容易。
如上所述，分离关注点很重要。
接下来，是否构建独立的表示层/应用层实际上是基于不同参数（即资源，时间，成本，可伸缩性等）做出的决定。我建议调查MVC/MVP设计模式，将您的演示逻辑从业务逻辑中分离出来，并考虑您的应用程序将如何在每个平台上呈现，以及最佳投资时间和金钱的位置。
你肯定不想要两个应用程序。尝试从视图中分离业务逻辑和控制器逻辑。
根据应用程序的复杂程度，差异可能只有一个额外的css文件（媒体类型为“手持”）到分离后端Web服务（如上所述）。在中间的是让所有的服务器代码如下格局
这对于使用模板化视图（JSP，Rails等）的系统来说特别有效，但也可以用于PHP。
如果您的网站可能拥有更多显示器，前端可以与Web服务配合良好，或者前端正在由分离的各方开发，则后端Web服务是一个好主意。
1）中的数据库的一切
2）一，中央商业逻辑层。这可能是网络服务，JavaBeans的，等有可能是纯网上或移动唯一的业务逻辑。没关系，把它放在一个地方。
3）多元表示层。 Web表示层将调用Web服务并为常规浏览器生成。移动表示层将调用相同的功能，但是将它们呈现为针对移动应用进行了优化。
如果进行多个项目，解决了一个错误，或将一个功能中就意味着你必须做它在两个不同的地点，从而加倍您的建筑和bugfixing时间。
或者，你可以离开在业务逻辑层相同的“幕后”的一切，让人们看到的是业务逻辑的网站或移动网站的不同的表现形式。
希望有所帮助。