Ran Pleasant

Do anyone know of an solid accounting open source library that contains methods for calculating asset depreciations?

Thanks,

abalfazl hossein wrote:...still can not understadn how strategy pattern works...

I'm giving a business example using different ways of calculating interest rates. Interest rates can be calculated using a give number of days in a month and a given number of days in a years, such as 30/360, 30/364, and 30/365. If we put these different calculations into different objects we might first create an abstract super class name InterestCalculation and then create the following subclasses: InterestCalculation30/360, InterestCalculation30/364, and InterestCalculation30/365. Now we can design a loan object that has a field to hold an object of type InterestCalculation which will handled calculating the interest of the loan. Of course different loans might take use different interest calcualtions. To handle this we just plug-in the correct subclass instance of InterestCalculation into the instance of a loan. If we didn't use the Strategy Pattern then we would probably have to have some type of big IF/ELSE IF statement in our loan class to handle the different calculations. Any time you see a number of If/Else If statements in an object it is probably in need of the Strategy pattern.

Ran

Ifteqar

Most of us like to get paid for doing that much work.

Maybe you should ask for something more specific.

Don Kiddick wrote:I'm confused whether this is a domain model (where our domain is the ui) or a presentation model (in which case we don't really have a domain model).

Domain objects encapsulate data and behavior representive of the entities and processes of a business or other type of institution. Examples: Invoice, LineItem, LineItemDetail, Item, Order, OrderLine, Stock, Product, Person, Customer, Account, Sale, Warehouse, Door [of warehouse], Truck, Driver, Cargo, Route, Student, Grade, ClassRoom, Course, etc. If an object does not encapsulate a part of a business, etc., then it is not a domain object. Objects that encapsulate services or GUI components are not domain objects. Domain objects may or may not be directly stored in a database. Domain objects may or may not be the objects put into the models of a GUI page/form.

Most Web applications use what Martin Fowler refers to an Anemic Domain Model, in which domain objects encapsulate data but no behavior. This almost always results in applications that are basically procedural in nature. For example, in a true domain model an invoice object can calculate the total thus you'll see the method "invoice.getTotal()". But in an anemic domain model you will see the calculation in a service object, such as "invoiceSerivce.getInvoiceTotal(invoice)" or "invoiceSerivce.getInvoiceTotal(invoiceId)".

If you want to work with true domain objects [data and behaviors] you should learn Object-Oriented Analysis and Design (OOAD). For learning OOAD I highly suggest the book Applying UML and Patterns by Craig Larman.

Inheritance in JPA or Hibernate will take care of what you need. Just make A, B, and C all subclasses of an Abstract class and map them in.

Of course, if A, B, and C cannot logically be subclasses of the same super class then you need to reconsider the design of the table.

Paul

Thanks for clearing that up.

Ran

Arun Prasath wrote:Hello All,

I am using EJB/JPA (Hibernate) in a project. I need to lock the record and show it to the user on (UI) page. I should not realase the lock until the user updates the record or cancel the action, such a way that same record should not be updated by other user ( probably by throwing optimistic locking exception when such attempts made). ..


Could you please give some efficient solution.?

In the book "JE2EE Design Patterns" by William Crawford (O'Reilly) they have the "Lockable Design Pattern" for locking a object and ensuring that it is release after a given period of inactivity. I have never used the pattern myself and cannot offer any information on how well it works but it may be worth looking into.

Ran

Mark Spritzler wrote:This exception occurs when you don't have all your data in your objects, then leave the confines of a Session object.

So if I lazy load a Collection say Parent has a Collection of Children. If Children is lazy loaded and I call getChildren in the Parent object, and there is no Session open, then yoiu have no way to load that data, so it throws that exception. Either eager load the data when you query, or call the code within a Session.

Mark

If the collection is marked as Lazy you can only access it within the confines of the Session. If you successfully make a call to the collection within the confines of the Session and then move outside of the confines of the Session it will still throw the exception. This is because the Session object is actually stored within your entity object and that Session object is accessed every time the getter method is called.

Someone please correct me if the above is wrong.

Ran

Indu

I don't see any configuration where the "mysessionFactory" bean is being injected into the sessionFactory field, thus you get the Null exception. Therefore, you need to lookup the bean "mysessionFactory" and set it in the sessionFactory field.

Ran Pleasant

Perry Terrance wrote:Actually this relationship is not circular/cyclic - since there is no direct-connection between STUDENT and SCHOOL OFFICIALS.

I was actually referring to the relationship between Activity and Student and between Official and Activity. Unless you use lazy loading you can easily pull a lot of data.

I will need to stick with this design though because it was designated that a table of just SCHOOL ACTIVITIES will be needed.

I do agree that SCHOOL ACTIVITIES is needed, I was just suggesting that one more table is needed. However, if you are force to go with the tables you have then all I can say is that I know that game well. I cannot count the times over the last 20 years that I was told my reall nice object model would not workd because I had to use the existing tables. It's just part of the profession, but if it was easy they wouldn't need you.

In terms of coding JPA2 though, it should still work right to do the Insert coding as I mentioned above?

Well, give it a try and let us know the results of your testing.

Hendra Kurniawan wrote:I'm still confused with the concept DI. In a nutshell, I perceive that DI is basically only aims to loosen coupling. Some help here? thanks

It's not the only goal, but it is the major goal. Another major benefit of DI is being allowed to write code without having to worry about where other objects are coming from. For exmaple, you can write a service that uses a couple of DAOs without having to think about creating or getting the DAOs. The field type for each DAO would be an interface and the intefaces would be implemented by whatever objects are injected. This allows you to unit test your service using dummy DAOs that implement the interfaces and then later implementing the DI with the actual DAO objects and doing your integration testings.

And that is why I love Spring!

Perry

I must respectfully disagree with your design. The student, the school official, and the school activity should all be existing records. What you want to do is to connect the student to an school activity. Thus, you need a fouth entity that reflects registration in the activity. I would also suggest that the school official probably does not need a list of his activities, these can be pulled by query when they are needed. Likewise with the student. Circlar relationships can be a source of major problems. For instance in your design, you might read one student resulting in a pull of all of his activities, which pulls the officials, which pulls all of their activities, which......... Object relations is one of those areas where you "shouldn't just because you can".

I assume that this design is part of a learning experience. However, if this is a production design then you should ask yourself, Does an address really need to point back to its owner?

I'm with Paul on this. The best way to meet that deadline is to get the "Java persistence with Hibernate" book and spending a day or two (plus evenings) reading it and playing with Hibernate in a small non-web/non-gui application. The day or two spent actually learning Hibernate will more than make up for itself as you continue your actual development. You have to know how to use the tool in order to use the tool. Use Hibernate right and persistence is easy, use it wrong you will pay for it.

Why? So that you in the future you don't go insane trying to find an easy to prevent bug.

There are many situations where Hibernate (and yourself) will compare instances of the ID class to see if they are both encapsulating the same primary key. If you don't override both the equals(...) and hashCode() methods you could possibly get a false positive and a false negative. Wrost of all it would probably be very hard to repeat any such problem, thus the bug would be a monster to find. In light of Murphy's Law the bug will most likely show up during a demo with a customer or upper management.

Ran