The cloud system based on the iphone-structure formation

We've been trying to make it easy and quick for users to share their favorite pictures. In fact, the first product release was a version of Pinterest, used to collect a market roadmap. After the initial network release, we realized that there are some difficulties in uploading images, so we have been working on new methods. We first tried on the iphone and wanted to launch Android apps in the near future. Because at the beginning, we can only concentrate on One direction.

There will be a series of (3-5) articles about how iphone apps are built. Here we'll talk about architectural details and publish some code later. The first article will show all the pictures. Well, to tell you the truth, that's all we have:

I have mentioned in my previous report that each layer is a cost investment. In fact, at first we didn't have the "phone.services" layer. This is what we later found in mobile phones using the middle tier to cache data can greatly improve performance. The following outlines the purpose of each layer.

Data Layer

Now you may think that we will use SQL Server as our primary data store. But we are using BizSpark, Microsoft produced a world-class project, can fully assume the responsibility of the backend database server. Without extensive Microsoft experience, we may not be responding to why we don't choose SQL Server. 99% of our access to the database is done through the stored program, and only 32 are available through the database native SQL tools (none of which can be exploited on these networks without the possibility of SQL injection attacks). We believe that the value of a database is only in the storage of data. Our stored programs are very short and there is no logic between them. In the future I will post some of our data structure in the blog, and you will see some aspects of intentional nonstandard.

Bit.services Layers

Before we start storming the collectibles, we have to think about other things. Will include a foothold in a suitable application for Facebook gaming apps, and finally back to our starting point. But before we had to do some other testing, we established the "23BITS.COM,LLC". That's why we've named the namespace "Bit." Very friendly, short, easy to input and noticeable, right?

The basic services layer should provide a connection to the database, perform any operation on the database, and provide a simple entity type for the asp.net layer. These services are the same as other network types and iphone applications. More detailed answers will be given on this point in future discussions. There will be 12 or so services to protect security, user profiles, collections, forums, communities, and other features that have not yet started. Dependencies between services are managed by using Ninject by DI (Dependency injection). Theoretically these services for hardware support can be divided independently, and we will separate them after the strength grows.

Internet bounday (asp.net MVC3.5)

The present is still asp.net MVC3, but it can also be run as MVC4 and handled infinitely close to MVC4. We will soon upgrade and then use more methods to make Web API technology cooler! It also responds to the call of basic JSON. Then there will be a blog about how we are protecting our system. Although the API now works on the iphone, the API will also appear on Android and windows in the near future.

Bit.clientservices

Of course, the customer service design pattern does not mean that you can only have one client and one service. In this case, we also have a service that relies on our backend servers for the iphone client. It will promote communication on the iphone by applying the clientservices layer to the service locally. The most needed concern is how to make a call to the server without disrupting the iphone's application, even when the innerwebs is low. However, it will accomplish this mission well.

Phone.services

We came to the final layer, which is a very special platform. This layer was added after some actual tests, and the results of the tests found that the performance of the handset was dramatically improved by simply adding a small amount of cache. Maybe there are some things Facebook apps can use. So we gave Bit.clientservices a cache that allowed it to respond at a high speed. As we continue digging deeper into the bit.clientservices details, we also find that the portable layer can be leveraged on Android and Windows Mobile apps. Very lightweight, mainly for clientservices calls. You just need to know what you can cache and what you can't cache, and you need to know the specifics of UI control. So with it, your local Facebook apps will get a new boost.

The above is an introduction to all the service layers and more details will be reported in the sequel. (Compile/Zhonghao Wang/revisers original from Collectedit)

(Responsible editor: The good of the Legacy)