Discuss the source code of quartz. net

Always searching. net excellent scheduler project, it seems that there is only one Z transplanted from Java. net, hereinafter referred to as Qn. There are also a lot of people on the Internet who are writing introductory tutorials, but there are more people who like it. I have been down its source code for a long time and have no time to read it. Recently, I have been idle, I went to the latest version and turned it on. It was a big drop. I don't know if it was because of my level too many times. I really felt that the Qn code was difficult to implement in terms of structure and programming style, when reading this article, I always feel that the code is obscure, which is far from the code of Microsoft's open-source Enterprise Library. I didn't want to read a few paragraphs at the beginning, so I went online to see if anyone analyzed his source code and found several so-called source code structure analysis tutorials, most of them are configuration tutorials. So the following is a bunch of cool words.

I also hope that my article experts will not be enlightened. Below I will stamp the Qn code for several sins (In addition, the source code I wrote down is 1.0 ):

1. Interface flood, but lack of layers:

For example:

Bored interface: ischedulerfactory. I can't see any function of this interface. Is it a metaphor that the user tries to use the abstract factory mode to use Qn in code? OK, this is understandable, but let's look at the implementation class stdschedulerfactory. Let's use the abstract factory. The prototype of the Public constructor is public stdschedulerfactory (namevaluecollection props ), abstract Factory configuration complexity can be imagined. What makes me more confused is that stdschedulerfactory has another static attribute defaultscheduler, which seems to be the meaning of the static method create, which is a simple help class, the Code semantics is messy. Look at another implementation class directschedulerfactory. The first line is Private Static readonly directschedulerfactory instance = new directschedulerfactory (); Singleton mode? I vomit blood ~ The implementation concepts of the same interface are different from those of the Code initiator. the user is confused, and the abstraction of ischedulerfactory levels becomes meaningless.

Island interface: iremotablequartzscheduler. Take a closer look at the ischeduler interface. The literal semantics should be iremotablequartzscheduler: ischeduler. Look at the code. The iremotablequartzscheduler interface and ischeduler interface are almost the same, I read it patiently because I changed the instanceid after using jobstore and could not implement ischeduler to create an iremotablequartzscheduler. However, in fact, the iremotablequartzscheduler implementation class quartzscheduler has the function of implementing ischeduler, and so on... what does it sound like? Clever, you have sniffed the taste of the adapter mode. Clever, the author indeed used the "adapter mode" in stdscheduler, but the implementation is also somewhat far-fetched. instanceid is actually initialized externally, I vomit blood again ~ Don't worry. In addition, almost all the Code uses quartzscheduler without using the iremotablequartzscheduler interface. This isolated interface does not provide us with the plug-in function ~.

Incomplete interface: ijobstore, which is used to resident the job information. Everyone would have thought that ijobstore can resident the job information. However, you may find out the code of stdschedulerfactory, the database storage mode must be inherited from jobstoresupport. Although jobstoresupport also implements ijobstore, The stdschedulerfactory Code contains this section to determine if (JS is jobstoresupport). What are the problems? The ijobstore information is insufficient. This type of code directly disrupts internal consistency, and we cannot continue to join if (JS is myjobstore). I think it is better to abstract ijobstoresupport in depth, in this way, you do not need to use jobstoresupport to enjoy dbprovider configuration.

Okay, this is an interface problem. Let's look at the programming style problem:

Frequent intercall: I found that the Qn code often displays A.M (B), B. N (A), and this Code is just to assign a property. B and B. a. I really don't understand how this design is created. I think it is better to use an abmanager to coordinate the AB call and then use new abmanager (a, B) to maintain the independence of AB?

Method Code is super long: at the beginning, we can see that there are 700 lines of stdschedulerfactory's instantiate method, you can retrieve attributes from the configuration file and assign values to the objects. In this case, at least 1/3 of the code can be written, while admiring the strong strength of the author, I can't help but doubt the robustness of the Qn code.

Boring virtual method: if you look at the code, you will find that the N-class instance methods are basically virtual methods, but if you come up with a virtual method, you will feel helpless, even several methods that are reloaded are all virtual methods. Let's crash. It seems that the virtual methods in the Code are almost written without thinking, not simply to provide users with flexibility.

Project files and namespaces are messy: project files are not organized in a unified manner. You will wonder if the SPI folder represents simpleinterface, but you will find triggerfiredbundle, when you find stdscheduler in the impl directory, you will find that its interfaces are in the root directory. There are always too many accidents and surprises to be secretly hidden in other places.

Let's look at the third-party plug-ins:

Log4net pain: we accidentally found that the ilog interface used everywhere in the Code actually comes from a third-party Code. For those who do not want to use log4net, We must drag the sink common. log. DLL, I always think that the key interfaces should be defined by myself, and we should not make our interfaces affected by third-party code (of course, I swear that you will not replace the third-party class library version ). Finally, let's take a look at ilog. By taking a closer look at the code, you will find that the Enable attributes are useless. in the Code, there are many places that do not care about these attributes.

 

To sum up, qN is a scheduler class library known as an enterprise class. However, whether the quality of its code has reached the enterprise level that the outside world boast is indeed worth discussing. However, we can also see that qN is indeed quite attractive, for example, the flexibility of jobdatamap, the separation of trigger and job, and other design ideas are worthy of reference. If you do not work hard on code refactoring, as an open-source project, it will not be as deeply rooted in the hearts of enterpriselibrary. We hope that the Qn in the future will be better and better. After all, scheduler under. NET is not common.

PS: Tell me who found the open-source scheduler framework under the excellent. NET platform.