ios中框架设计模式_使用ios上的框架设计多商店电子商务

最新推荐文章于 2024-09-11 10:00:04 发布

weixin_26735419

最新推荐文章于 2024-09-11 10:00:04 发布

阅读量336

点赞数

文章标签：设计模式 ios

原文链接：https://medium.com/flawless-app-stories/designing-a-multi-store-e-commerce-using-frameworks-on-ios-80f6cc982713

版权

ios中框架设计模式

A few months ago, I joined a fashion retail company owner of multiple unrelated physical stores. For example they have one store selling multi-brand premium clothing, another selling jewellery and accessories, luxury house furnitures and decoration, etc.

几个月前，我加入了一家时尚零售公司，拥有多家不相关的实体店。例如，他们有一家商店销售多品牌的高级服装，另一家商店销售珠宝和配饰，豪宅家具和装饰品等。

In the past, the company didn’t have a centralized IT team, and each store had the freedom of deciding the e-commerce platform, since they are treated as independent sub-company. They ended up having one using Magento, another Shopify, another Salesforce, etc.

过去，公司没有集中的IT团队，每家商店都可以自由决定电子商务平台，因为它们被视为独立的子公司。他们最终有一个使用Magento，另一个Shopify，另一个Salesforce等。

I joined a newly created team, as the only iOS engineer, with the mission of providing common tech solutions across all the stores, in order to reduce the operating costs, time to market, development cycle time. I was asked to design and build an e-commerce for one of the stores (using Magento GraphQL as backend), that could be easily adapted and reused by others.

我加入了一个新成立的团队，是唯一的iOS工程师，其使命是在所有商店中提供通用技术解决方案，以减少运营成本，缩短上市时间，缩短开发周期。我被要求为其中一家商店设计并建立一个电子商务(使用Magento GraphQL作为后端)，其他人可以轻松地对其进行改编和重用。

I saw 3 possible approaches to take:

我看到了3种可能的方法：

Have a different project for each store without reusing anything
每个商店都有一个不同的项目，而无需重复使用任何东西
Have a different project for each store but reusing common modules/features (such as Wishlist, Cart manager, login/registration)
每个商店都有一个不同的项目，但是重复使用了通用的模块/功能(例如，愿望清单，购物车管理员，登录/注册)
Have one project for a generic e-commerce, and a small framework for each store that will only contain relevant code and configuration
有一个通用电子商务项目，并且每个商店都有一个小框架，其中仅包含相关代码和配置

The good thing of being the only iOS engineer is that I can design the architecture the way I consider best. On the downside, I didn’t have any fellow mobile engineer to share my thoughts, discuss pros/cons, validate my hypothesis.

成为唯一的iOS工程师的好处是，我可以按照自己认为最好的方式设计架构。不利的一面是，我没有其他移动工程师来分享我的想法，讨论优点/缺点，验证我的假设。

I decided to go with option 3 because understood was the most scalable and maintainable, providing a pragmatic solution with less amount of code.Also because the similarities across the analyzed stores were far greater than the differences. The main challenge was that stores use different backend, therefore they don’t share a common network layer.

我之所以选择选项3，是因为理解是最具可扩展性和可维护性的，它提供了一种实用的解决方案，使用的代码量更少，而且因为所分析商店之间的相似性远大于差异。主要挑战是商店使用不同的后端，因此它们不共享公共网络层。

Using a separate target and framework for each store, ensures:

为每个商店使用单独的目标和框架，以确保：

The business logic is encapsulated within the framework
业务逻辑封装在框架中
Changes in one store won’t affect others
一家商店的变化不会影响其他商店
Reduced compilation time and app size since only the relevant code for the selected target will be compiled, bundled and shipped to the users.
减少了编译时间和应用程序大小，因为仅将针对选定目标的相关代码进行编译，捆绑和交付给用户。

选择的架构 (The chosen architecture)

Image for post — High level architecture diagram

Came up with this diagram defining 3 main layers:

该图定义了3个主要层：

Main app containing the core modules/features of any e-commerce.
包含任何电子商务的核心模块/功能的主应用程序。
Every store has its own framework, defining configurations such as public keys, supported languages, as well as the colors, fonts, icons, background images and finally encapsulating the integration with the backend and the payment gateway.
每个商店都有自己的框架，定义配置(例如公钥，受支持的语言以及颜色，字体，图标，背景图像)，最后封装与后端和支付网关的集成。
Contains protocols used by main app and conformed by the stores providing a unidirectional data flow. Also defines models to be used across the app such as App State, User model, etc.
包含由主应用程序使用的协议，并由商店遵循以提供单向数据流。还定义了要在整个应用中使用的模型，例如应用状态，用户模型等。

调色板演示教程 (Demo tutorial for color palette)

Create a new Project > Single View App, name DemoFrameworks
创建一个新项目> Single View App，命名为DemoFrameworks
Create a new target: File > New > Target > Framework
创建一个新目标：“文件”>“新建”>“目标”>“框架”
Specify a name, in this case Shared
指定一个名称，在这种情况下为共享
Ensure is embedded in the application:
确保已嵌入应用程序中：

Repeat the same process of creating framework for StoreA and StoreB. The file tree should look like this:

重复为StoreA和StoreB创建框架的相同过程。文件树应如下所示：

We add a new file defining a public protocol inside Shared

我们在Shared中添加一个定义公共协议的新文件

In order to conform to this protocol inside StoreA and StoreB frameworks, we need to add the dependency.

为了在StoreA和StoreB框架内符合此协议，我们需要添加依赖项。

Select the project in the project navigator
在项目导航器中选择项目
Select the framework StoreA in the target list
在目标列表中选择框架StoreA
In the General tab, tap the + button inside Frameworks and Libraries
在“常规”选项卡中，点击“框架和库”内的+按钮。
Add Shared
添加共享
Repeat steps for StoreB
对StoreB重复步骤

Now we can import Shared and conform to the protocol ColorPalette. Create the following file inside StoreA framework.

现在我们可以导入Shared并遵守协议ColorPalette 。在StoreA框架中创建以下文件。

And this one inside StoreB:

而StoreB中的这个：

What we need is a way to compile the app using either StoreA or StoreB, not both at the same time. We can achieve this by using a different target and scheme.

我们需要的是一种使用StoreA或StoreB而不是同时使用两者编译应用程序的方法。我们可以通过使用不同的目标和方案来实现。

Select the Project in the Project Navigator
在项目浏览器中选择项目
Right click in DemoFrameworks target, duplicate
右键单击DemoFrameworks目标，重复
Notice that a new .plist has been created, this will give the flexibility to have different configuration per target
注意，已经创建了一个新的.plist，这将为每个目标提供灵活的不同配置
Notice as well, that a new scheme has been created for this new target
还要注意，已经为此新目标创建了新方案
Rename both targets and schemes like so:
重命名目标和方案，如下所示：

Then, we make sure only StoreA framework is embedded in StoreA Target, and the same for StoreB.

然后，我们确保只有StoreA框架嵌入到StoreA Target中，而StoreB也是如此。

Select StoreA Target, General tab
选择StoreA Target，常规选项卡
In Framework, Libraries and Embedded Content, remove StoreB.framework
在框架，库和嵌入式内容中，删除StoreB.framework
Repeat for StoreB Target, deleting StoreA.framework from the embedded list
对StoreB Target重复上述步骤，从嵌入式列表中删除StoreA.framework

我们如何测试呢？ (How can we test this?)

We can use a structure similar to a Strategy pattern to decide in runtime which implementation of the protocol in Shared to use, based on the Scheme that is running.

我们可以使用类似于策略模式的结构，在运行时根据正在运行的Scheme来决定要使用Shared中协议的哪个实现。

Let’s start by creating this file in main app:

让我们从在主应用程序中创建此文件开始：

Then, in SceneDelegate.swift we pass an instance of ColorKit to the view, injecting the correct palette based on a Swift Flag, should look like this:

然后，在SceneDelegate.swift中，我们将ColorKit的一个实例传递给视图，并基于Swift Flag注入正确的调色板，如下所示：

Set the foreground color of the text in ContentView:

在ContentView中设置文本的前景色：

Finally, to add the Swift Flag:

最后，添加Swift标志：

Select the Project in the Project Navigator
在项目浏览器中选择项目
Select StoreA Target, tab Build Settings
选择StoreA Target ，然后选择构建设置
Find Other Swift Flags, and add a new flag with name STOREA and prefix -D: -DSTOREA
查找其他Swift标志，并添加一个名称为STOREA和前缀-D的新标志： -DSTOREA
Repeat the same for StoreB
对StoreB重复相同的操作