Silverlight quick development platform-rethink the omnipotent entity god_model

Silverlight quick development platform is a configuration-based development platform.

It is impossible to define a data model like a specific development business system to generate a specific entity class.

Because our goal is to develop business systems without coding

In this way, there is a conflict. Because there is no encoding, it is impossible to produce a specific model object to describe a specific domain model.

Binding data on Silverlight must all be entities. What should I do? Some cool people are engaged in objects similar to datatable. Although it is very cool, I think it is not advisable!

In this way, god_model is born with 10 thousand objects. If we cannot design specific objects, we can design 10 thousand objects with extraordinary and all-encompassing capabilities.

It is an abstract entity. You cannot see what it represents, but it can represent anything.

The attributes defined in it are non-specific attributes, so str1, str2, str3. ...... str50 is better. It is mainly used to carry data and bind data.

Because we do not have code, as long as the system can run normally, for example, str1 represents the employee's name, it can be normally indicated, and normal binding will be OK, we

You do not need to worry about why it is bound with str1, rather than the more intuitive name user_name.

It doesn't matter. Whatever it is, it's just Euler's normal operation.

Our goal is to do everything possible without coding, but it is almost impossible to completely eliminate coding, unless the business system is too simple.

In the end, the technical framework can only solve technical problems. The core business logic cannot all be componentized. It is time for developers to show their skills.

Hey, it's my turn to play!

Hey, what is this? How is it str1, str2, str3?

Isn't it finished? God, help me, I don't understand!

Okay. This is a problem. It seems to be a framework issue.

The following scenarios were created:

Architect: there is no way. Our platform is based on the abstract model of the omnipotent entity. It cannot be a specific model.

Programmer: the development in this architecture is quite troublesome.

Architect: The trouble is the part of the Code that needs to be extended. You can see how powerful the platform is. The encapsulated 80% of the Code does not need to be developed, and it takes almost five minutes to develop a picture.

The better thing is that your software is not developed but configured. You can modify the configuration file software at any time to quickly modify it.

And you do not need to release it. The configuration is assigned to our database.

Programmer: Think about it too. Think about the good platform. Indeed, it has completely liberated me from the original code slaves. It can only be done in a few days, there are still a bunch of functional requirements after the completion,

Now, in less than half an hour, I had to go to the bathroom and smoke together. The time was not a problem and I was still able to handle it with ease. This gave me more time to focus on the core business logic, there is more time to think.

Hmm ...... Certainly, this platform is powerful.

But I will write the following extension code.

I think there will always be a bit uncomfortable. Although I think of a good platform, this pain has subsided a lot, but the pain is still hidden.

Architect: Looking at the expressions of the programmer, it seems that you have read the feelings. As an architect, the achievements made above are indeed a reflection of your value,

But with a tail, it always feels not perfect.

Is there really no way? Is it true that the technology is poor?

No! Don't draw a conclusion so early that there is no way, and there are always more ways than difficulties.

Never bow your head in the face of difficulties. You can only say that you haven't thought of it yet. It doesn't mean you can never think of it.

These problems must be addressed as one technical point.

The above two roles are my own torture. I think that a senior architect must write code in person. Otherwise, you do not know how difficult the architecture you designed is.

Maybe you are already outstanding in some aspects, at least you can be outstanding.

 

The solution to the problem is contingent, but it will never be able to break away from the subjective initiative of people.

Maybe some strange thoughts may flash into your mind at a moment.

At this time, you need to keep reasoning with your own thinking. Maybe you want the answer not far away. You don't take the initiative to explore it. You may not know the answer before you.

One afternoon, when designing another design, similar situations are all needed, from concrete to abstract, and then how to abstract to specific problems.

That is, the previously designed asynchronous data retrieval problem.

Here we will briefly describe the requirement: Silverlight needs to retrieve the relevant data based on a key in some scenarios.

We only need to configure the platform in the form of ep_info Select Code, name, tel, email, fax from ep_info where id = '# conn #'

What does it mean? We configure an asynchronous data source to query enterprise information.

How can I obtain the code from the Silverlight end? Ajax ('ep _ info') OK is done. After the logic encapsulated by the platform, the returned objects are described by god_model.

The omnipotent entity of all things. At this time, the Silverlight side will see str1, str2, str3

In fact, developers expect godinfo ["code"] to be much more intuitive than godinfo. str1. The specific luxury hope godinfo. Code is never possible,

No code definition in godinfo

Don't expect this high level. godinfo ["code"] is also OK like datatable, not unacceptable. After all, we are a configuration-based platform and there is no specific class.

In fact, we want to have a mapping relationship, code = str1, name = str2, tel = str3, email = str4

The code is actually solved by going to godinfo. str1,

So how to create a ing relationship, write it by yourself?

If the problem is not solved by yourself, the problem is converted, and the inconvenience during use is passed on to the creation of the ing relationship.

So we must have created the mapping relationship when we created god_info. The specific str1 and str2 are actually just a data carrier.

Select Code, name, tel, email, fax from ep_info where id = '# conn #'

If the preceding SQL statement finds data, such as code, name, tel, and emial, the data will be stored from str1 and str2 in the unified asynchronous processing of core code.

At the same time, the mapping relationship is established. Code = str1, name = str2, tel = str3, email = str4

In this way, you can use godinfo ["code"] On the SL end, and do not care about str1.

If there are other similar requirements in the future, we will configure an SQL on the configuration platform, so that the Silverlight side can quickly and conveniently solve the problem.

Here we provide a mapping idea.

Therefore, our data dictionary is a mapping relationship.

I didn't think of this value before, but I just thought about it all before, godinfo. str1

In this case, we only need to design an indexer in god_model to input the attribute name of a specific service. The object will find the specific abstract Attribute Based on the mapping relationship and then return the data.

OK, so that we can hide the abstract Part of god_model.

 

After reading this article, you may be confused about what the god_model is doing. After all, this is not something in the industry, but our own innovative design.

Why is it named in god_model?"Shen"

As said, it is normal to shoot bricks.

Although you cannot be invited to Zhongnanhai as you did, I still welcome you to take a picture.Brick, leave your footprints!