前后端分离的项目，如何管理页面的展现？配置数据应该存放在哪端？

[stg609]

一个前后端分离的项目，前端使用至少2种方式：web端和移动端。前端通过调用后端的 api 来访问服务。

假设现在有2个需求：
1. 允许用户修改前端的布局，比如本来菜单在顶部，用户可以移动到底部。
2. 允许用户对菜单的顺序进行调整。

用户调整后，换一个新浏览器或重新安装 APP ，只要通过登陆账户，那就能恢复之前的设定。

我的疑问：
1.不同前端的布局是否应该尽量保证统一？但是统一的前端意味着会失去一些为某些设备特有的设定，比如 iwatch 和 ipad 上对于同一款 app ，大家是怎么考虑的？
2.这些菜单的顺序、页面布局的配置应该放在后端吗？如果放在后端，岂不是后端依赖前端了？

[娃都会打酱油了]

没弄过，不过就算可以做定制化设置，那么肯定移动端的只能在移动端展示，web端的也只能在web端展示，最多就是一些位置之类的两者可以共通

[圣殿骑士18]

1、从架构上来说，前端可以理解为“视图”，不同的设备，具有不同的视图，这本来就很正常。 2、如1的情况，如果不同设备还有不同视图，那么设备多了可能视图就很多，维护量就大，这个时候适当的使用一些配置，来合并一些设备端的视图，这不能叫后端依赖前端这么肤浅，我们编码的根本目的是什么，是复用，提高研发效率。说依赖不依赖，要不要依赖，判断的原则也是开发和维护效率，而不是依赖本身是好是坏。 3、要使用多少视图，要实现多少的配置，这个是动态的，和设计者的能力，偏好有关，没有定论。

[以专业开发人员为伍]

可能你是从传统的小asp.net 办公软件的角度说的“前后端”。比如说几个人刚学了1年asp.net，他们搞一个asp.net程序，那么他们可能整天（不管是在办公室还是在上下班的路上）都满脑子以为自己这几个人分工为“前、后”台程序员。而对于现代的大一点的系统，集中的大型业务服务器设计开发才是专业服务设计，而 asp.net、php 之类的程序员做的也不过就是前台。

所以是从职能上来区分架构，而不是从什么“前后台”来区分。换句话说这里的“后台”不是完全去纠结任何一个代码运行在 web 服务器上，不是说写一个肤浅的服务器代码就标榜自己是“后台工程师”了，而是看这种后台是不是专业地针对各种前端系统的统一服务器系统。

如果你满脑子就是某类小的页面的开发，那么你的界面就跟“增删改查”绑在一起，浑浑噩噩分不开。这个时候你说的“后台”也就是纠结于这个 UI 层的那些东西了！！

[以专业开发人员为伍]

随便举个例子，比如说一个工厂有3各车间、有20种产品流程、有120种流程操作（加工录入表单），那么前端需要获得所有操作节点的配置信息、在保存每一种表单之后另一些前端实例立刻立刻刷新往下操作的信息（比如说一道工序技术之后立刻通知下一道工序的看板系统上显示待办任务新汇总数量），这就需要前后端配合。后端负责隔离前端，让前端跟数据库（同时也就同时也关联上任何后端分布式SOA服务等等层面）相分离，不要纠结低级的什么数据库之类的东西。

前端代码包括 asp.net c# 代码。包括 asp.net 网站解决方案和工程的创建、文件管理、c# 代码等等都是前端的工作。

如果你没有什么经验，你可以这样认为，后端就是要刻意让前端接触不到数据库，前端不知道后端用什么数据库、用了几个数据库实例、许多 SOA 服务是怎么访问的。前端专注于根据需求来对 Model 建模，然后把这种 Model 需求跟服务器开发者协商。这就是前后端分离。

[以专业开发人员为伍]

你会发现前端设计者要把精力放到业务 Model 建模上，如果你满脑子都是什么“统一客户端布局、菜单布局”之类的，这写如果有必要的话也可以麻烦人家服务器端给你维系接口调用，但是前端也完全可以自己开发一个什么 ashx 之类的来把配置放到自己前端的 asp.net 网站服务器的 app_data 目录下。

这里最重要区分前端和服务器端的标准是职能、专业性，而不是什么用没用 c# 代码来写。都是干大事儿的人，区分前端和服务器端设计开发的原则是解耦和提供通用服务平台（发布同一套企业服务服务平台给不同的前端系统），而不是纠结一点点含糊其辞的 UI 特性来争论前后台。

当你只是纠结一点点 UI 特性时，其实没有定论，其实这说明你只是在满脑子研究一个刚入门的小界面，而还没有设计开发一个大一点的软件。

[sp1234_maJia]

有的“满脑子只有技术”的人说：我想把所有的界面布局细节都在 SQL Server 数据库表里边定义出来，而不论是初学者还是高级的开发者反而是把界面定义使用 html 文件形式保存起来。初学者是没有研究过需要拆解布局的机制，而高级开发者是清楚地知道改变和部署 html 是举手之劳、反而是硬要把布局弄到什么关系数据库里边其实结果只能做千篇一律的非常简单的界面，反而是找麻烦的事情。

那么你把不同前端i同的菜单布局仍然自然而然地保存到他们自己的 aspx、html、xaml 等文件中，还是你要弄一堆什么 Model 来请服务器端做一堆接口帮你管理？你随便！！！！

重点在于，前后端分离的机制根本不是为了这个目的。

[以专业开发人员为伍]

这就好像我最近接触的2个“项目”，国家级的，花了百万，其实分包到我这里用2、3万块钱就给你人家做了（中间差价都是层层分给关系户了），这类项目上线之后并没有什么人用，互联网上有无数的这类官僚的地方性服务网站系统。那么这类东西就可以纠结什么 UI 数据往哪一个层放，甚至把一大堆时髦的“层”也弄进来，多养几个技术人员，掩饰洗钱。

其它的方面，我们讲求实用性，讲求真实的架构目的。

[以专业开发人员为伍]

引用 楼主 stg609 的回复:

2.这些菜单的顺序、页面布局的配置应该放在后端吗？如果放在后端，岂不是后端依赖前端了？

不管服务器端设计开发者是否愿意支持前端产品经理的接口操作申请，这都不算事“依赖”。把这个说成是依赖显然就是搞反了服务器系统的设计开发的真实目的。服务器系统是干大事儿的，被这种需求牵制住，只能是无奈。