如何构建这个 Symfony web 项目? [英] How to structure this Symfony web project?

查看:18
本文介绍了如何构建这个 Symfony web 项目?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是 Symfony 的新手,不知道如何最好地构建我的网络项目.该解决方案必须适应 3 个用例:

I am new to Symfony and am not sure how to best structure my web project. The solution must accommodate 3 use cases:

  1. 公共访问 www.mydomain.com 以供一般用途
  2. 会员只能访问 member.mydomain.com
  3. 管理员访问 admin.mydomain.com

所有三个虚拟主机都指向 Symfony/web 目录

All three virtual hosts point to the Symfony /web directory

问题:

这是我的 Symfony 项目中的 3 个独立应用程序(例如前端"、后端"和管理员"或公共"、成员"、管理员")吗?

Is this 3 separate applications in my Symfony project (e.g. "frontend", "backend" and "admin" or "public", "member", "admin")?

  • 如果有一些重复的代码(例如,生成成员列表在所有 3 个应用程序中是通用的,但呈现方式不同),这是一个好方法吗?
  • 当用户访问 *.mydomain.com 时,我将如何根据子域路由到各种应用程序?这个路由逻辑应该放在 Symfony 的哪个位置?

或者,这个应用程序是否包含适用于上述每个用例的模块?

Or, is this one application with modules for each of the above use cases?

我无权访问 apache 中的 httpd.conf 来为虚拟主机指定默认页面.我只能使用主机提供程序的 cPanel 为每个子域指定一个目录.

I do not have access to httpd.conf in apache to specify a default page for virtual hosts. I can only specify a directory for each subdomain using the hostin provider's cPanel.

推荐答案

如果不知道每个域/应用程序/任何东西的实际职责,这很难说.这是您必须根据项目要求回答的问题……没有一种策略可以针对每个用例推荐.

This is hard to say without knowing the actual responsibilities of each domain/app/whatever. This is something you have to answer based on the requirements of your project... there is no single strategy one can recommend for every use case.

话虽如此,我认为您最多可以制作两个应用程序 - 一个用作前端并包括成员"功能.我认为这些拖拽可能是一个单一的应用程序的原因是因为你想要从另一个生成链接(如果它们是单独的应用程序,这很难做到) - 即.每个人都可以访问主页并说常见问题解答,但只有成员可以访问下载或其他内容,但它们仍然是同一个站点.

With that said I think at most you have the makings of two applications - One would serve as frontend and also include the "members" functionality. The reson i think these tow ar probably a sinlge app is because youll want to generate links to one from the other (which is incredibly hard to do if they are seperate applications) - ie. EVERYONE has access to the homepage and say the FAQ, but only members have access to Downloads or something, but still they are the same site.

另一个应用程序将用于后端并保留管理功能.无论您可以共享多少个应用程序,只需创建一个符号链接,然后适当地指向 apache,例如:

The other app would be for the backend and hold the admin functionality. Regardless of how many apps you can share the same web dir sinmply make a symlink and then point apache appropriately for example:

cd htdocs
ln -s SF_ROOT_DIR/web frontend
ln -s SF_ROOT_DIR/web backend

现在您可以将您的 cpanel 设置指向 domain.com 和 members.domain.com 的 htdocs/frontend 并指向 admin.domain.comhtdocs/backend.

Now you can point your cpanel set to htdocs/frontend for domain.com and members.domain.com and point admin.domain.com to htdocs/backend.

然后你可以改变你的 .htaccess 看起来像这样:

Then you could change your .htaccess to look something like this:

Options +FollowSymLinks +ExecCGI

<IfModule mod_rewrite.c>
  RewriteEngine On

  # we check if the .html version is here (caching)
  RewriteRule ^$ index.html [QSA]
  RewriteRule ^([^.]+)$ $1.html [QSA]
  RewriteCond %{REQUEST_FILENAME} !-f

  # no, so we redirect to our front web controller

  # if subdomain is admin.* then use backend.php application
  RewriteCond %{SERVER_NAME} ^admin\..*$
  RewriteRule ^(.*)$ backend.php [QSA,L]

  # not admin so we use the frontend app
  RewriteRule ^(.*)$ index.php [QSA,L]

</IfModule>

这样您应该可以在两个应用中使用 no_script_name.

This way you should be able to use no_script_name with both apps.

做同样事情的另一种方法是将您的 index.php 修改为如下所示:

Another way to do the same thing would be to modify your index.php to something like the following:

require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

if(0 === strpos($_SERVER['SERVER_NAME'], 'admin'){
  $app = 'backend';
}
else
{
  $app = 'frontend';
}


$configuration = ProjectConfiguration::getApplicationConfiguration($app, 'prod', false);
sfContext::createInstance($configuration)->dispatch();

您可以随意修改应用名称检测,但您懂的.

You can modify the app name detection however you like but you get the idea.

通过这两种方法,您可以根据子域进行一些基本确定,并且无论我们讨论的应用程序数量如何,您都可以应用此策略,无论您只使用我推荐的 2 个还是使用 3 个.

With both of the approaches you can do some basic determination based on subdomain, and you can apply this strategy regardless of the number of apps we are talking about whther you only use my recommended 2 or if you use 3.

另一种方法是制作一个本土应用程序.假设每个应用程序实际上只是整个应用程序的一个方面,我喜欢走这条路.但是,我认为成员、非成员和管理员对模块的定义过于宽泛.

The alterantive is to make one homegenous application. Assuming each of applications is really just one facet of the overall application i like to go this route. However, I would consider members, non-members, and admin too broad a definition for modules.

如果你这样做,你可能最终会在控制器中执行大量的操作.相反,我会针对实际问题制作单独的模块.此外,没有真正的理由在此处使用子域 - 仅使用 url 的一部分(即/admin 或/members)来使用特定模块要容易得多.

If you did it that way you could potentially end up with an insane amount of actions in the controllers. Instead i would make seperate modules for actual concerns. Additionally theres no real reason to use subdomains here - its much easier to just use a segment of the url (ie. /admin or /members) to use specific modules.

例如让我们接受用户...通常会有一个管理区域,因此我们可以使用管理生成器来实现该功能并调用模块 UserAdmin 或类似的东西.然后对于userland的东西,我们可能只有模块User,它可以处理公开的个人资料查看和列表,用户的个人资料编辑等等.然后对于实际登录,我们可能有模块 UserAuth ,它严格处理诸如登录/注销和忘记密码请求之类的事情,等等.您可以将任何 url 路由到这些模块中的任何一个,因此您的路由可能如下所示:

For example lets take users... Typically theres going to be an admin area so we can use the admin generator for that functionality and call the module UserAdmin or something similar. Then for the userland stuff we might just have the module User which would handle public profile viewing and listing, profile editing by users and all that stuff. Then for actual login we might have the module UserAuth which strictly handles stuff like login/logout and forgotten password requests and what not. You can route any url to any one of these modules, so your routing might look something like this:

user_login:
  url: /login
  params: {module: UserAuth, action: login}

user_logout:
  url: /logout
  params: {module: UserAuth, action: logout}

user_password:
  url: /forgot-password
  params: {module: UserAuth, action: recoverPassword}

user_reset:
  url: /password/reset/:token
  params: {module: UserAuth, action: resetPassword}

user_profile:
  url: /members/:username
  params: {module: user, action: showProfile}

user_index:
  url: /members
  params: {module: User, action: index}

user_default:
  url: /members/:action
  params: {module: User}

admin_user:
  class:   sfDoctrineRouteCollection
  options:
    Module: UserAdmin
    model: User
    prefix_path: /admin/user

以这种方式做事的最后一步是确保您使用 security.yml 中的适当凭证要求保护适当的模块和操作,并且您还适当地分配了凭证.

The last step in doing things this way is to make sure you secure the appropriate modules and actions with the proper credential requirements in security.yml and that you also assign credentials appropriately.

这篇关于如何构建这个 Symfony web 项目?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆