Shipatrioc http://www.jdon.com Nov 30, 2004 8:55 PM Reply I am not smart, I have learned that Java, Java, but more, more obvious, not only there is no hair in the brain, but there is a kind of fire Into the demon. I started to use EJB. When I first graduated, I met with the synonym of J2EE, but the system developed is very slow, I am still old, how can I use the speed block developed by CGI, CGI is Multi-process, but servlets can be multithreaded, isn't a heavyweight? Then someone stands out, the top ten sins of the entity bean. Then seem to becomes the eyeball. After the teacher, my teacher is from Going abroad specially talked about a class, specifically mentioned Spring, I went to the big and small forum, oh, this is not Spring's world! Go to learn, see Spring is not universal, it There is no distributed deployment, or to combine EJB to achieve a distributed system. Then suddenly found a book that made me happy, that is, the Spring author's WITHOUT EJB, I saw some, it seems that it is to let us Rational use EJB, also said that 80% of the system does not need to be distributed, then I confused, the system we developed in this 80%, or in another 20%. The book I didn't persist. Because the brain began to revolution. Hey, the confused writer is confused by the Java code! It is so much righteousness, and everyone knows what I am talking about :) Look at the title, I will know, I have a strange. !
Re: Definition of the size of the project! Published: DEC 1, 2004 10:26 AM
Reply Poster: Banq Post article: 3774 / From: Shanghai / Registration time: 2002-08 We know that demand is the mother of software, only human practice needs, will have software to promote software development, if someone tries to Human demand is fingerd on hand, only two people: 1. Don't have a heart; 2. Fool. This person tried to point out that the 80% system in our practices did not need XXX, making such an assertion, have exceeded the extreme two words, I advocate technology can be used to use extreme, for example, you can say that Spring technology is perfect, I am unambiguous, because technical personnel talk about technology, extremes are normal. However, the technicians try to guide the needs of the technology, no matter who he is, I am extremely dishedeled, and must be a blood of his dog, no matter what the world famous, the famous chicken and dogs.
Re: Definition of the size of the project! Published: DEC 1, 2004 11:45 AM
Reply Poster: ShipatrioC published article: 6 / Registration time: 2003-08 Thank you, Banq, but it is true, read your reply, I thought I said something wrong, I'm still saying, I have said. I have turned it. I have been a lot in this forum, and I have learned a lot of things in it. But there is a feeling that people here seem to be rich in fire (it may be like this to have a professional person), Therefore, it is also a war, huh, huh, huh. Since I sent it, I still want to listen to everyone's opinion. Let's describe the demand: Small and medium-sized projects use the web server is enough, but large-scale project use EJB or use Web Service, or directly call RMI to make the project more elastic, but there is also a lot of development and performance costs. So when we conduct project development, how can this scale of the project size? I There is also the same post on 9CBS. If you are interested, you can play! Thank you! Http://community.9cbs.net/expert/topic/3603/3603919.xml? Temp = 5.256289E-02
Re: Definition of the size of the project! Published: DEC 1, 2004 12:46 PM
Reply Poster: ljshan published article: 8 / Registration time: 2004-11 Dry technology seems to always feel "popular is good", EJB just came out, there was a must-have to develop with EJB, regardless of the system, as long as used At the EJB, I feel how good the system will, how practical in my heart; then slowly think that EJB is a shortcoming, and many people have a poor, and there is a popular container. Spring, AOP ..., perhaps future This shortcoming of Light-Weight is criticized ... The fashion happens in the technicians, but it happens that the manager can be miserable! In fact, I think EJB is good, Light-Weight Container is not good (Light-Weight is not developing on the shoulders of EJB technology?), The key to the software technology you choose and your needs (including functional implementation and system Sexual non-functional demand) is for the road, if you write a guest book is an independent project, is it necessary to use EJB, Light-Weight? Of course, in general, most people will use the Light-Weight Container practice, this is the fact, but everyone understands the 80/20 rule. If the project is used as an object, maybe your project is 20 Part of the rules do not have exceptions. Suo so much, the foremost is not possible to leave the needs of the project itself, and also consider the implementation and maintenance cost of the software, it is considered from the perspective of the project, not just from the technical level. Re: Definition of the size of the project! Published: DEC 1, 2004 5:22 PM
Reply Poster: Shipatrioc Post article: 6 / Registration time: 2003-08 Thank you ljshan's attention, I also understand that the fact is the first, the project can be done, the user is satisfied is the first, one project development What tools should consider many factors, such as hardware, funds, and developers' skill levels, I am actually a very simple question in this discussion, maybe my expression is not very exactly. Simple, it is a survey, also It is an exchange of communication. What frameworks are selected for sale, what is the case of how many people can meet at the same time?
Re: Definition of the size of the project! Published: DEC 2, 2004 9:15 AM
Reply Poster: Banq Post article: 3774 / From: Shanghai / registration time: 2002-08 Shipatrioc misunderstood me, I am the author of the WITHOUT EJB, as a professional, actually for another area: demand , For assertion, more, all the logic behind him relies on this site that can not stand up. If the demand can assert, then the silver born is born. The problem is that the demand is always changed, you can't make it difficult for your customer needs, and your only thing to do is: Do your best to adapt. As an example of a small business, it may be a small system today. It doesn't need to be distributed, but the company's export profit, the size of Chinese enterprises is a vision of the world, when After you give him a system that does not have a scalability, this system may become a stumbling block that hinders him. You have to adapt to his development, you must change the architecture, rewrite writing? Fortunately, Spring provides reliable scalability, which is his wise, but if you ask for WITHOUT EJB, then where you have a value, just a comment: 80% does not need distributed EJB?
Re: De: Direction of the project! Published: DEC 2, 2004 9:46 AM Reply Popular: Banq Post article: 3774 / From: Shanghai / Registration time: 2002-08 Published my personal opinion on major issues: "Small and medium-sized Projects are sufficient, but large-scale projects use EJB or use Web Service, or directly call RMI to make the project more elastic, but there are many costs on development and performance. Then we When conducting project development, how does the scale of the project are defined? "First," The price of many development and performance "is a misunderstanding, and some people repeatedly destroy EJB results. I am using JDONSD framework and JBuilder. In the case of development tools, a small system of a ten model, I will reform all the features of the rendezvous, and I can see my ESTORE source code. Http://www.jdon.com/my/train/controllaction.do So, to form a quick development mode on EJB, you need practice or external training guidance, the software itself is a professional thing, if you still expect to be like VB, Delphi, only a few graduates can be customized, then software is not a high-tech industry. If you take mature EJB development model, you can form size development and even form a blue-collar worker's industrial pattern. I have taught Indian Niit J2EE courses. This course is primarily ejb. In India, I can enter NIIT to learn this course, and I can go abroad, this is a bunch of blue-collar industries in India. Regarding the cost of EJB performance, this is a misunderstanding, in my books and materials, I have been here to quote the founder of JBoss: "The advantage of EJB is the first is the advantage of performance," if you think EJB performance issues, It means that your EJB is going to do, this problem has been repeated in my previous post, http://www.jdon.com/my/ is developed using EJB, do you think the performance is low? Looking at it, I use JMeter to test the performance of an EJB system. Some people say that EJB is a development cost problem. This is a lie. Development cost is always your quality problem. Maybe you are suitable for blue-collar programmers, but you are doing model, architecture planning and programming, speed efficiency Can you not be low? Is this the cost problem of EJB development? Therefore, there is no problem with the scale of the project, and some are just something outside the technology. If you don't do it anymore, you don't have to use the structure of a scalable, of course, if you take it more Ok, indicating that your software is higher, but you must be able to provide these high quality systems at low cost. If you can't get it, use the JSP database, or use .NET good. In addition to one of the above, the rest I recommend that you use a scalability architecture system. Of course, the scalability architecture is not just performance retractable, your design needs this, for example, your user authorization system needs to be a tree structure , Not Flat, flat, etc. Before Spring appears, EJB is a unique choice, but Spring is currently available in an intermediate selection, because Spring provides reliable EJB scalability, so you start using Spring, you can need to use EJB, save Spring Business Object You can implement it in the EJB container.
If you don't think Spring is complicated, you start recommending Spring, but don't be affected by "without ejb", otherwise you don't know where the road is, this is also the place where most people are now confused, I published on the programmer. "Chaotic Java World" is to show this confusion of programmers, but unfortunately, the actual problem has suffered from the blockacch of programmer magazine, and I will never write to programmer magazine. Re: Definition of the size of the project! Published: DEC 2, 2004 10:29 AM
Reply Poster: Banq Post article: 3774 / From: Shanghai / registration time: 2002-08 The onpicker is not targeted by the landlord, I am a borrow question, express some views on a general point of view, only for reference, may have some extreme views, also Please pay attention to critically. Welcome everyone to publish a view, not to people are the purpose of the JDON forum, so, no matter what people can be straightforward, I have said that "the sun is dead" means that there is no so-called technical authority here, but arguing, The true argument of rationality, the first speaker does not need to fight, the version of the brick will come at any time, but this can't hinder the freedom I speak, I am confident.
Re: Definition of the size of the project! Published: DEC 2, 2004 4:33 PM
Reply Poster: Nekesai published article: 25 / Registration time: 2004-10 Haha, Banq said good, admire. Really understand the essence of things, there is this masterpiece, ^ _ ^. Yes, the demand is never stopped, otherwise this world will stop can't stop (this sentence needs a certain philosophical background.). Our customers' business is very likely because the market also explosives growth. I have encountered such a project. The original customer's business is only in China. Later, it has been extended to Japan and Europe, and the problem of the entire system load is coming out, and it is because the domestic data can be affected, using a centralized style (On an application server), it is possible to directly connect to the server directly to the server, rather than the province's application server, which uses JSTATEMACHINE (is an open source) DAO VO and OSCache and some Pool. However, the increase in business in Japan and Europe has led to a large amount of data, and the entire user has all, huh, this time, Japan and Europe need their respective servers, then take data to data transmission, but business processes There are cross-servers and the database is also a one-to-one configuration. Oh, everyone guess, there is any problem, it is the scalability of Banq, and the business is global rather than local, huh, huh, the original system is changed to EJB, there is no way, will not tell me to use RMI. If you use RMI, what should I do if you don't tell me to use TRYX or JTOM, my day, then you should write an EJB container, saying that I am also afraid of the stability of myself. And performance is another problem, although I think I think my own technology is very good. Now it is completely changed to the lasting layer with EJB, and there is still a lot of headache pool, ^ _ ^. If you choose EJB, you will be fine. Ok, say this, some people will ask me, how much system business is like your customers, huh, I can only say that you don't understand EJB. Using EJB from the beginning, it is to use its scalability and some of the inherent services of the container, and you also explain that you are responsible for the customer, taking into account the future change, more than business changes. Because EJB is a distributed business component, what is a step-by-step, that is, it can participate in the calculation in any part, so that "complete" can be multiplexed. Know what is the realm of reuse now? Don't tell me that it is a class, listen to it is a business service. That is to say, if it is a order business, how is the current multiplex hierarchy to reuse such a business, rather than a class in the order, that is, we have to establish a method of service-oriented architecture (SOA). Oh, EJB is a step-by-step business component (don't just understand the EJB is a domain model, because that is just the entity bean, there is sessionbean, to understand the EJB, if you need an order business, Then call it directly from your app. Now let me talk about what EBJ is difficult to develop, honestly say that EJB cannot be developed, the only difficulty is that it is inconvenient, but the current JBuilder supports remote debugu is no problem. If the company or your team has a set of development frameworks, if the performance layer uses JSP Struts, the control layer and the application layer use Struts Command mode, the service layer uses Command Facade, and the persistence layer is DAO. The DAO is JDBC, or Hibernate is also good, or EJB does not matter.
So, you write this framework, you can of course use XDoclet, Velocity, etc. It is not difficult for you to develop anything. If you don't have something, you will develop Struts Hibernate. Ok, I certainly not the EJB's communicator, nor the opponents of other programs, what I have to say is that we must deeply understand the essence of things, so that you have lowered your risk, too Responsible for the user. If a user only invests 100,000 pieces on a small CRM system, you also give it to EJB, 100,000 to buy a WebLogci has problems, what do you say, of course, don't be EJB, but this is good. But it is definitely not because other programs are better than EJB, I don't have to use EJB. In fact, China does not understand a lot of essence, and it is not clear to EJB. Some people even have anything else, what is distributed, etc., why do you have a distributed and other things? That's the wind. Finally, I can tell you, even if I use Struts EJB or Struts Dao JDBC or Hibernate I can also build the entire system prototype (including basic CIUD and query and the entire system architecture), this is basically taking EJB with you Not EJB is no relationship. The risk of software technology is a small part of the entire risk. Re: Definition of the size of the project! Published: DEC 2, 2004 12:14 PM
Reply Poster: Kidwish Post article: 14 / Registration time: 2003-08 How does the technology change, he has more advanced, but human thinking can not be described well. At the same time, the process of project development can only see the current and possible future, and cannot be exhausted all changes. Therefore, it should maintain the evolution of the project during design and development, so that the project "live". As for technology, he should treat him as a protected resource. Here is the best example for Java and .Net, why is someone always says who is it? Because they have fallen into the phones of the technology! Did not see some facts! Or they stand in a highly "blind" command ...
Re: Definition of the scale of the project! Published: DEC 2, 2004 12:56 PM
Reply to: Banq Post article: 3774 / From: Shanghai / Registration time: 2002-08 Kidwish let the project "live" viewing is also what I want to express, I think that emphasizes scalability is to let the project "live" A good suggestion.
Re: Definition of the size of the project! Published: DEC 2, 2004 4:47 PM
Reply Poster: Nekesai published article: 25 / Registration time: 2004-10 Kidwish proposed problems, just I hope that he can make a solution to the problem. Here we are more concerned about how to make the project "live", and what we are considering how the project size is defined, because its "live", the project scope caused by this demand is blurred, and it has been blurred Otherwise, there is no "living". But we will guarantee the expansion of the "live" of this project from the technical perspective, which is scalability. Don't say that I still need to explain what is scalability, and the scalability is not only performance. It is easy to adapt to the change of business, and even physical changes on other networks and hardware.
Re: Definition of the size of the project! Published: DEC 2, 2004 4:54 PM
Reply Poster: Kidwish Post article: 14 / Registration time: 2003-08 "I think that emphasizes scalability is a good suggestion that makes the project" live "." I think it should be the scalability of the architecture. What is the telescopic? Most people may consider architectural factors in system functionality, but this is not enough, often ignoring non-functional considerations, such as quality, maintenance, skills, personnel, etc. So good architecture is not advocating: what lightweight container, EJB burden. It should be from the understanding of the problem domain, seeking a solution. The technology is to pay attention, I always feel a good designer, you should understand all kinds of technologies, but it is not paranoid as a "perfect" design! Re: Definition of the size of the project! Published: DEC 2, 2004 5:02 PM
Reply Poster: Kidwish Post article: 14 / Registration time: 2003-08 "Kidwish's question is very good, just I hope that he can solve the problem." I am also looking, but I know how difficult this is. Just like abstract ... However, I have found some things that have some effective methodological things. My point is to take a long time, flexible driving. A lot of good architectures, a lot of books in architecture mode. To seek a good architecture, I think the source is in your own hands - demand.
Re: Definition of the size of the project! Published: DEC 2, 2004 5:06 PM
Reply Poster: Kidwish Post article: 14 / Registration time: 2003-08 There is also something I think it is important to pay attention to "shadow" in the software project is the system and function that constantly expands! - "Shadow Promotion" My idea is to maintain growth, but pay attention to large particle size. PS: Some topics are far ...
Re: Definition of the size of the project! Published: DEC 2, 2004 6:04 PM
Reply Poster: Nekesai published article: 25 / Registration time: 2004-10 "" "" I think it should be the scalability of the architecture. What is the telescopic? Most people may consider architectural factors in system functionality, but this is not enough, often ignoring non-functional considerations, such as quality, maintenance, skills, personnel, etc. So good architecture is not advocating: what lightweight container, EJB burden. It should be from the understanding of the problem domain, seeking a solution. "" "" "" "" "" "" "" "" "" "" The direction is in the direction. However, what is the relationship between demand, maintenance, skills, and personnel have any relationship, and the change in demand should say that the changes in demand are related to these relationships, basically there is no relationship. It should be said that the changes in demand are basically the customer's presentation, then you have to do it. You have to do it, then you will need to change the risk assessment of the demand, the results are basically done, and that makes the system have good scalability to adapt. And if you bias the EJB and its containers and other lightweight containers, the EJB is undoubtedly the wind. If nothing else, consider how to adapt to the changes and expansion of customer business, and of course EJB is best. The means of other management directions is another problem with discussion.
Re: Definition of the size of the project! Published: DEC 2, 2004 8:49 PM
Reply to: Kidwish Post article: 14 / Registration time: 2003-08 "The scaling performance of the architecture provides a solution to the demand variation, but the management and control of demand changes is an orderly and granularity and the opposite of the demand change. It is back to affect the frequency of demand, which is from the direction of management. But what is the relationship between demand, maintenance, skills, personnel, and the changes in demand should say that the change of demand is related to these relationships? It is basically there is no relationship. It should be said that the changes in demand are basically the customer, then you have to do it. You have to do it, then you must conduct a risk assessment of the demand change, the result is basically doing, It is necessary to require a good scalability to be adapted. "No architecture can guarantee or meet the changes in demand, and can not meet the expansion of the system. The most closely is the architecture that has just been designed, and then it will change immediately after the development. Because the architecture is the product under demand, it is difficult to adapt to frequent demand variations, and the demand changes should be improved. Because we welcome demand changes! This is also advocated by XP / Agile. If the architecture goes to adapt to changes in demand, it can only be able to meet the needs. There is also what I don't say quality, maintenance, skills, personnel and needs, I just set them as "architectural factors", thus making some "architective choice". Re: Definition of the size of the project! Published: DEC 2, 2004 10:18 PM
Reply Poster: Nekesai Post article: 25 / Registration time: 2004-10 to to kidwish: <<<< No architecture can guarantee or meet changes in demand, and can not meet the system's expansion. The most closely is the architecture that has just been designed, and then it will change immediately after the development. Because the architecture is the product under demand, it is difficult to adapt to frequent demand variations, and the demand changes should be improved. Because we welcome demand changes! This is also advocated by XP / Agile. If the architecture goes to adapt to changes in demand, it can only be able to meet the needs. There is also what I don't say quality, maintenance, skills, personnel and needs, I just set them as "architectural factors", thus making some "architective choice". >>>>>>>>>>> Architecture says the EJB that I often cooperates, EJB is called business components, don't understand it, it is not just a domain model, what is business component, is a relatively independent business Logical packaged entities, I can use a order service to express a sessionbean, and the client will call my business through the service interface. If the order service changes (business logic changes, it is one of demand changes), I The owner can modify my sessionbean, and the client should not do any changes. If there is a new business to increase, my owner gives me a sessionbean brother (demand), if there is a new business Brother A needs to process first during my order business logic. If A is also my EJB brother, as long as it is called in my logic (business logic, demand is increased), if there are other brothers Application system requires changing in its own server, it is necessary to order business data to participate in it, which is called from its application (business logic changes, demand). Oh, you said that this provides a good means of adapting to demand changes from technology, you don't tell me what you said, I can do it with others, of course, but i I took you, if you also write another set of EJB, learn RMI, you will handle your business, wait, God. So the demand change is to be able to accommodate the business components, and different business components have different adaptability, which is the so-called system's telescopic ability. If you use the general javaclass as a business component, you should want to solve the problem above, you The head will be big, do you understand? Oh, okay, I think we always have a dislike, what is the architecture is to adapt to components that adapt to your demand change. Demand changes require changes in business components to adapt, architectures are just the services they need to complete business components. Re: Definition of the size of the project! Published: DEC 3, 2004 9:57 AM
Reply Poster: Kidwish Post article: 14 / Registration time: 2003-08 To Neksai I think your saying is paranoid a "perfect" program or design. EjB is good, but you can guarantee that he is not eliminated (I just Suppose ...) All your questions are from the perspective of technology, it is impossible to see the overall ...
Re: Definition of the size of the project! Published: DEC 3, 2004 10:46 AM
Reply Poster: Nekesai Post article: 25 / Registration time: 2004-10 I think you understand the wrong, how come I paranoid, from those information? I didn't express all problems technology angles. I can say that I am saying that there is more ways to say that it is whip or with eej, which is difficult to define the requirements of technical issues. What kind of technology is used is to discuss the problem of solving demand changes from technology. Then I recommend that it is preferred to use EJB technology. I also give example to illustrate a means of providing a means from a technical perspective. It is not deny that management management and control is more effective, you can see some suggestions and understandings about the changes in demand changes from management direction. I said that I have never been an EJB's communicator, nor is it supporters of other programs. I just want to choose the technical solution I think of a reasonable thing according to my understanding of the essence of the business. I have understood the technical plan. I also said that technology is just a small part of a risk. Don't look at it, I will say that I will see the overall situation from the technology. The program is to make a decision after you look at the full bureau. Of course, we must weigh, if you have anything Don't consider, in order to meet the scalability, of course, EJB, I said this. If you are eliminated in EJB, I can only tell you that there must be another kind of EJB appeared in all the benefits of ejb now (this sentence is good, why do you say this), not because now Hibernate Or there is a Spring framework that cannot be used as an EJB to eliminate the basis because they don't have an EJBDE advantage. Of course, if someone defines a better EJB specification, it is also the current EJB elimination. When you don't see EJB1.x, you have a new EJB2.0 to replace, not what OJB, don't think EJB1.x and EJB2.0 are not ejb, they are just a bit like and defined They are all the same father Sun, but they have a lot of different, then the EJB3.0 that is coming soon is coming out, of course, it is not the same as EJB2.0, say this, no matter whether it is The name of EJB2.0 and EJB3.0 will not change to Nekesai or Kidwish, this is not essential, the essence is that they all support distributed computing with EJB1.0, transaction container self-management, security and service container Provide advantage, no matter who replaces anyone, there must be these things. Oh, so I think "Can you guarantee that ejb is not eliminated?" Is a very stupid problem, asking if it is worthless, why, because I basically no matter whether it is EJB, I only take it? EJB is good, even if it comes to change your face, I want to become Nekesai1.0, you don't have to use, I will tell you that EJB has been eliminated, haha, this is a fool, Nekesai1.0 is not the same Do those of EJB, change soup. But if you change the medicine, it is like hibernate, it can't replace EJB. Why, think about it, think about something, don't be ignorant. Re: Definition of the scale of the project! Published: DEC 3, 2004 12:09 PM
