你如何组织你的匕首2模块和组件?[已关闭]
你有没有一个特定的包,你把所有与匕首相关的类?
或者,您是否将它们放在它们注入的相关类旁边,例如,如果您有一个 和 ,则将它们放在与 .MainActivityModule
MainActivityComponent
MainActivity
另外,我看到很多人将组件定义为内部类,例如在类内部定义的一个。你认为这是一个好的做法吗?ApplicationComponent
Application
你有没有一个特定的包,你把所有与匕首相关的类?
或者,您是否将它们放在它们注入的相关类旁边,例如,如果您有一个 和 ,则将它们放在与 .MainActivityModule
MainActivityComponent
MainActivity
另外,我看到很多人将组件定义为内部类,例如在类内部定义的一个。你认为这是一个好的做法吗?ApplicationComponent
Application
编辑:让我从这样一个事实开始,即这在这里接近事实,但这是一个反模式,正如Martin Fowler的文章这里(点击链接!)所描述的那样,它指定你不应该有一个和一个,你应该有一个和一个,里面有所有的映射器,演示器等。Data Domain Presentation Layering
MapperModule
PresenterModule
GalleryModule
SomeFeatureModule
实现此目的的明智方法是使用组件依赖关系来细分您拥有的每个功能的原始单例组件。我所描述的就是“全栈”分层,按特征分离。
下面写下的是“反模式”,您可以在其中将应用程序的顶级模块切割成“层”。这样做有许多缺点。别这样。但是你可以阅读它,并学习什么不该做。
原文:
通常,只要整个应用程序存在,你就会使用一个像 an 这样的单一实例来包含你在整个应用中使用的所有单例依赖项。您可以在 Application 类中实例化它,并使其可从其他位置访问。Component
ApplicationComponent
我目前的项目结构是:
+ injection
|- components
|-- ApplicationComponent.java
|- modules
|- data
|-- DbMapperModule.java
|-- ...
|- domain
|-- InteractorModule.java
|-- ...
|- presentation
|-- ...
|- utils
|-- ...
|- scope
|- subcomponents
|- data
|-- ...
|- domain
|-- DbMapperComponent.java
|-- ...
|- presentation
|-- ...
|- utils
|-- ...
|-- AppContextComponent.java
|-- AppDataComponent.java
|-- AppDomainComponent.java
|-- AppPresentationComponent.java
|-- AppUtilsComponent.java
例如,我的是这样的:
public enum Injector {
INSTANCE;
private ApplicationComponent applicationComponent;
private Injector() {
}
public ApplicationComponent getApplicationComponent() {
return applicationComponent;
}
ApplicationComponent initializeApplicationComponent(CustomApplication customApplication) {
AppContextModule appContextModule = new AppContextModule(customApplication);
RealmModule realmModule = new RealmModule(customApplication.getRealmHolder());
applicationComponent = DaggerApplicationComponent.builder()
.appContextModule(appContextModule)
.realmModule(realmModule)
.build();
return applicationComponent;
}
}
而且你需要一个可以注入到任何你想要注入的类的包保护字段中的。ApplicationComponent
@Singleton
@Component(modules = {
AppContextModule.class,
DbMapperModule.class,
DbTaskModule.class,
RealmModule.class,
RepositoryModule.class,
InteractorModule.class,
ManagerModule.class,
ServiceModule.class,
PresenterModule.class,
JobManagerModule.class,
XmlPersisterModule.class
})
public interface ApplicationComponent
extends AppContextComponent, AppDataComponent, AppDomainComponent, AppUtilsComponent, AppPresentationComponent {
void inject(CustomApplication customApplication);
void inject(DashboardActivity dashboardActivity);
...
}
对我来说,这将是一个,但这实际上并不是它的意思。这些只是创建子作用域的一种方法,而不是将组件切割成更小部件的方法。因此,我继承的接口实际上只是一个正常的预置方法。其他人也一样。AppContextComponent
@Subcomponent
interface
public interface AppContextComponent {
CustomApplication customApplication();
Context applicationContext();
AppConfig appConfig();
PackageManager packageManager();
AlarmManager alarmManager();
}
组件依赖关系(允许您像子组件一样进行子作用域)不允许多个作用域组件,这也意味着您的模块将被取消作用域。这是因为您无法从多个作用域继承,就像您无法从Java中的多个类继承一样。
无作用域提供程序使模块不会在每次注入调用时保留单个实例,而是保留一个新实例。若要获取作用域内依赖项,还需要在模块提供程序方法上提供作用域。
@Module
public class InteractorModule {
@Provides
@Singleton
public LeftNavigationDrawerInteractor leftNavigationDrawerInteractor() {
return new LeftNavigationDrawerInteractorImpl();
}
...
}
在应用程序中,如果将 Singleton 组件用于所有位置,则不需要更多组件,除非创建子作用域。如果需要,您甚至可以考虑使模块成为视图和演示者的完整数据提供程序。
@Component(dependencies = {ApplicationComponent.class}, modules = {DetailActivityModule.class})
@ActivityScope
public interface DetailActivityComponent extends ApplicationComponent {
DataObject data();
void inject(DetailActivity detailActivity);
}
@Module
public class DetailActivityModule {
private String parameter;
public DetailActivityModule(String parameter) {
this.parameter = parameter;
}
@Provides
public DataObject data(RealmHolder realmHolder) {
Realm realm = realmHolder.getRealm();
return realm.where(DataObject.class).equalTo("parameter", parameter).findFirst();
}
}
子范围允许您拥有演示者的多个实例,然后可以存储状态。这在例如 Mortar/Flow 中是有意义的,其中每个屏幕都有自己的“路径”,每个路径都有自己的组件 - 将数据作为“蓝图”提供。
public class FirstPath
extends BasePath {
public static final String TAG = " FirstPath";
public final int parameter;
public FirstPath(int parameter) {
this.parameter = parameter;
}
//...
@Override
public int getLayout() {
return R.layout.path_first;
}
@Override
public FirstViewComponent createComponent() {
FirstPath.FirstViewComponent firstViewComponent = DaggerFirstPath_FirstViewComponent.builder()
.applicationComponent(InjectorService.obtain())
.firstViewModule(new FirstPath.FirstViewModule(parameter))
.build();
return firstViewComponent;
}
@Override
public String getScopeName() {
return TAG + "_" + parameter;
}
@ViewScope //needed
@Component(dependencies = {ApplicationComponent.class}, modules = {FirstViewModule.class})
public interface FirstViewComponent
extends ApplicationComponent {
String data();
FirstViewPresenter firstViewPresenter();
void inject(FirstView firstView);
void inject(FirstViewPresenter firstViewPresenter);
}
@Module
public static class FirstViewModule {
private int parameter;
public FirstViewModule(int parameter) {
this.parameter = parameter;
}
@Provides
public String data(Context context) {
return context.getString(parameter);
}
@Provides
@ViewScope //needed to preserve scope
public FirstViewPresenter firstViewPresenter() {
return new FirstViewPresenter();
}
}
public static class FirstViewPresenter
extends ViewPresenter<FirstView> {
public static final String TAG = FirstViewPresenter.class.getSimpleName();
@Inject
String data;
public FirstViewPresenter() {
Log.d(TAG, "First View Presenter created: " + toString());
}
@Override
protected void onEnterScope(MortarScope scope) {
super.onEnterScope(scope);
FirstViewComponent firstViewComponent = scope.getService(DaggerService.TAG);
firstViewComponent.inject(this);
Log.d(TAG, "Data [" + data + "] and other objects injected to first presenter.");
}
@Override
protected void onSave(Bundle outState) {
super.onSave(outState);
FirstView firstView = getView();
outState.putString("input", firstView.getInput());
}
@Override
protected void onLoad(Bundle savedInstanceState) {
super.onLoad(savedInstanceState);
if(!hasView()) {
return;
}
FirstView firstView = getView();
if(savedInstanceState != null) { //needed check
firstView.setInput(savedInstanceState.getString("input"));
}
}
public void goToNextActivity() {
FirstPath firstPath = Path.get(getView().getContext());
if(firstPath.parameter != R.string.hello_world) {
Flow.get(getView()).set(new FirstPath(R.string.hello_world));
} else {
Flow.get(getView()).set(new SecondPath());
}
}
}
}
你有没有一个特定的包,你把所有与匕首相关的类?
或者你把它们放在它们注入的相关类旁边,例如,如果你有一个MainActivityModule和MainActivityComponent,你把它们放在与MainActivity相同的包里。
我对此没有太多经验,但我可以向你展示我的方法。也许一些有更多经验的人可以改进该解决方案或提供他们的观点。
我通常像这样组织Dagger 2课程:
- di
|
+-- ApplicationComponent class
|
+-- modules
|
+-- AndroidModule class
|
+-- WebServiceModule class
|
+-- ...
|
di
包包含与 Dagger 2 和依赖注入相关的类。ApplicationComponent
modules
包装包含匕首 2 模块我不为每个活动创建模块。模块对特定功能进行分组。例如,与系统紧密连接的元素,如共享首选项的界面,EventBus(如果您使用的是类似的东西),网络连接等可能位于.如果您的项目具有 WebService 的重要接口,或者有很多接口,则可以将它们分组到 中。例如,如果您的应用程序负责分析网络,并且具有许多用于与网络相关的类似任务的接口,则可以将这些接口分组到 中。当您的应用程序很简单时,您可能会只有一个模块。当它很复杂时,你可以有很多模块。在我看来,你不应该在单个模块中有很多接口。在这种情况下,您可以考虑将它们拆分为单独的模块。还可以在单独的模块中保留一些特定于项目的业务逻辑。AndroidModule
WebServiceModule
NetworkModule
另外,我看到很多人将组件定义为内部类,例如在应用程序类中定义的应用程序组件。你认为这是一个好的做法吗?
我不确定这是好的做法还是坏的做法。我认为没有必要这样做。可以在类扩展类中创建公共静态方法,该方法将实例作为单例返回。这是一个更简单的解决方案,我们应该只有一个类的一个实例。如果我们想在单元测试中模拟 Context,我们可以接受 Context 作为参数,并在应用程序代码中根据情况传递应用程序上下文或活动上下文。get()
Application
Application
Application
请注意,这只是我的方法,一些更有经验的开发人员可能会以不同的方式组织他们的项目。