将多个 .net Web 应用程序整合到一个套件中

发布于 2024-11-15 18:39:19 字数 659 浏览 4 评论 0原文

我正在参与一个项目,我们将构建许多相关但又不同的 Web 应用程序。很可能会有不同的团队开发不同的网络应用程序。

将有许多包含通用功能的共享组件 DLL,例如用户管理、内容管理。还有许多网页需要共享,例如登录、导航、错误处理、用户配置文件管理、图像二进制内容,可能还有许多其他目前尚不清楚的内容。 关键是应用程序需要能够共享页面/内容以及 DLL。

我们使用 VS2010 并使用 MVC 3 和 Razor。

不同的应用程序应作为套件部署,从用户的角度来看,它们可以很好地集成。

将 DLL/通用库推送到自己的项目应该不是问题,问题是如何订购 Web 应用程序。

我看到的一些替代方案:

  1. 使用区域来划分不同的区域 套件中的应用程序。这可能 我是一团糟吗?人们在哪里 可能会踩到对方的脚趾吗?任何人 具有使用空间的经验 这?
  2. 使用单独的网络应用程序,但在 相同的解决方案。这将提供一个 更干净的切割,但使重复使用变得更加困难? 是否可以重用cshtml(aspx) 文件?我如何获得这些 WebApps 一起在一个套房里。之前 我使用过的java经验丰富 sitemesh,它几乎吸引了 不同的网址有不同的 WAR(WebApps) 文件并将其全部放入 与常见的一页 导航。
  3. 使用单独的解决方案和单独的网络应用程序不知道在 2 之上会提供什么。

I'm in a project where we're going to build a number of related but yet different webapplications. Most likely there will be different teams working on the different web apps.

There will be a number of shared components DLLs that contain commmon functionality, e.g. user management, content management. There will also be a number of web pages that need to be shared, e.g. login, navigation, error handling, user profile management, binary content as images, probably lots of other stuff, unclear at the moment.
The key is that the applications need to be able to share pages/content as well as DLLs

We are on VS2010 and using MVC 3, with Razor.

The different applicaitons should be deployed as suite, where it all integrates nicely from the users perspective.

Pushing out the DLLs/common libraries to its own projects shouldn't be a problem, the question is how to order the webapps.

Some alternatives I see:

  1. Use areas to divide the different
    applications in the suite. This may
    me a monolithic mess? where people
    may step on each other toes? Anyone
    experienced with using spaces for
    this?
  2. Use separate webapps but within the
    same solution. This would provide a
    cleaner cut, but make reuse harder?
    Is it possible to reuse cshtml(aspx)
    files? How do I get these WebApps
    together in a suite. Previously
    experienced with java I've use
    sitemesh, which pretty much pulls in
    different URL from different
    WAR(WebApps) files and puts it all
    into one page with common
    navigation.
  3. Use separate solution and separate webapps don't know where that would offer on top of 2.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

允世 2024-11-22 18:39:19

将会有许多包含通用功能的共享组件 DLL,例如用户管理、内容管理。

共享组件应该不是问题,但通常最好构建一个服务层并让一个团队仅处理服务。否则,所有团队都很容易添加只有他们需要的功能,这通常会导致一团糟。

还有许多网页需要共享,例如登录、导航、错误处理、用户配置文件管理、图像二进制内容,可能还有很多其他东西,目前还不清楚

同样的事情也适用于网页。恕我直言,这通常不是一个好主意。最好让所有网站共享相同的登录名(单点登录)并拥有 http://account.yoursite.com< /a> 完成所有帐户管理的网站。

问题是如何订购网络应用程序。

子域。单点登录。

There will be a number of shared components DLLs that contain commmon functionality, e.g. user management, content management.

shared components should not be a problem, but it's usually better to build a service layer and let one team handle services only. Otherwise it's quite easy for all teams to add features that only they need which usually ends up with a big mess.

There will also be a number of web pages that need to be shared, e.g. login, navigation, error handling, user profile management, binary content as images, probably lots of other stuff, unclear at the moment

Same thig goes for web pages. imho it's usually not a good idea. It's better to let all web sites share the same login (single sign on) and have a http://account.yoursite.com web site where all account management is done.

the question is how to order the webapps.

subdomains. Single sig on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文