从现有数据访问层重写视图
我准备将我的网络应用程序的视图重新启动为全新的、经过严格测试的、锐利的视图喷射机器。我的遗留页面中嵌入了大量的学习曲线，我最好放弃它并从头开始使用 jQuery1.4/jUI/MVC3 的规范堆栈。
问题是如何最轻松地迁移我现有的后端（基于 Unity 和 nHibernate，外观质量还过得去，因此它应该是一个相当干净的解耦） - 我是否应该考虑任何其他策略或资源 除了 mvcScafolling 作为最近的帖子？
关于如何使流程最高效的任何建议？我可以做的任何事情（或雇用来完成的事情）都可以提高代码生成部分可以最好地获取我的数据结构的程度吗？
精炼>>
如果使用包含相同概念结构（客户、产品、购物车）的后端 - 只是名称不同。
将 Music Store FE（与 mvc3 一起分发）连接到一个相当强大的前端（musicstore）到我的数据不是一种可行的方法吗？
I'm ready to reboot my web app's views into a brand spanking new, rigorously testing, sharply razored view spewing machine. There's tons of learning curve embedded in my legacy pages and i'm better off just walking away from it and starting from scratch with the canonical stack of jQuery1.4/jUI/MVC3.
The question is how to most easily migrate my existing back-end (based on Unity and nHibernate, the facades are of passible quality so it should be a fairly clean decoupling) - should i be looking at any other strategy or resource besides mvcScafolling as this recent post?
Any bit of advice on how to make the process most productive? anything i can do (or hire to have done) the enhances how well the code gen part can best pick up my data structures?
REFINEMENT>>
If working with a back-end that contains the same conceptual structures (customer, product, cart) - just different names.
Wouldn't bolting the Music Store FE (as distributed with mvc3) be a feasible way to meld or merge in a fairly robust front end (musicstore) to my data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论