Better Faster Lighter Java [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Better Faster Lighter Java [Electronic resources] - نسخه متنی

Justin Gehtland; Bruce A. Tate

نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
افزودن یادداشت
افزودن یادداشت جدید








10.1 A Brief Look at the Existing Search Feature


The search feature that comes
with jPetStore takes
one or more keywords separated by spaces and returns a list of
animals with a name or category that includes the term. A search for
"dog" turns up six results, while a
search for "snake" nets one.
However, a search for "venomless"
gets no results, even though animal EST-11 is called the Venomless
Rattlesnake. Even worse, none of the other pages (such as the Help
page) shows up in the search at all; neither will any other pages you
might add, unless they're an animal entry in the
database.

The search feature has the following architecture (shown in Figure 10-1):

Any page of the jPetStore application may contain
a search entry box with Search button.

Clicking the button fires a request (for
/shop/searchProducts.do) passing the keywords
along as part of the request.

petstore-servlet.xml, the configuration file for
the MVC portion of the jPetStore Spring
application, has the following definition:

<bean name="/shop/searchProducts.do" 
class="org.springframework.samples.jpetstore.web.spring.SearchProductsController">
<property name="petStore"><ref bean="petStore"/></property>
</bean>

This creates a handler for the
"/shop/searchProducts.do" request
and maps it to an instance of
SearchProductsController, passing along an
instance of petStoreImpl called
petStore.

SearchProductsController instantiates an instance
of a class that implements the ProductsDao
interface, asking it to search the database for the specified
keywords.

ProductsDao queries the database and creates an
instance of Product for each returned row.

ProductDao passes a HashMap
containing all of the Product instances back to
SearchProductsController.

SearchProductsController creates a new
ModelAndView instance, passing in the name of the
JSP page to display the results (SearchProducts)
and the HashMap of values. The JSP page then
renders the results using the PagedListHolder
control (a list/table with built-in paging functionality).




Figure 10-1. The original jPetStore search architecture

Only the ProductsDao knows how to interact with
the underlying data. Product is a straightforward
class with information about each product, and the view
(SearchProducts.jsp) simply iterates through the
returned results to create the output page.


10.1.1 Deciding on the Spider


We've identified how the

current search feature works and its
limitations: the search feature only searches products in the
database, not the site as a whole, and even then it
doesn't search all available data about the
products. The results it returns are extremely limitedthough
well-formatted.

The Simple Spider is a crawler-based search feature instead of
focusing on the database: it searches everywhere on the site, not
just the products table, and it treats any textual information
visible to users as part of the search domain. The Spider does have a
major limitationsince it is based on a web crawler, it can
only catalog pages linked to other pages on the site. If a page is
only accessible via some server-side logic (for instance, selecting a
product from a drop-down list and submitting the form to the server,
which returns a client-side or server-side redirect), the crawler
never reaches that page and it won't be part of the
search.

With a problem like this, in which a feature of the application is
too limited to be of much service to our users, we have to decide
between refining the existing service or replacing it entirely. The
limitation of the jPetStore search is partly due
to the fundamental nature of the service (it searches the database,
not the site). Refining it to accomplish the full-site search would
be horribly inefficient. The Spider is the obvious solution, but we
must consider what we are already dealing with (remember, you are
what you eat). If jPetStore uses a lot of
server-side logic to handle navigation, the Spider simply
won't be able to provide a complete catalog. In this
case, though, all the navigation on the site is handled client-side,
so the Spider is a perfect fit for solving our problem and coexisting
with our current application.


10.1.2 Extending jPetStore


We have decided that an

existing
service layer of the application is unsuited to our current needs.
Additionally, we have decided that replacing the service with a new
one is the appropriate solution. This situation is a perfect test of
extension: how easy will it be to replace this service? Will it
involve new code? Changes to existing code? Or just changes to our
configuration services?

In order to replace the existing functionality with the Simple
Spider, we need to change the output formatting a little (our returns
will display full URLs instead of product instances), write a new
controller that knows to launch the Simple Spider instead of the
ProductsDao object, and change our mapping layer
to point to the new controller. Finally, we'll use
Spider's configuration service so Spider works
better with the new web site.

Looking at these requirements, we can already see
we'll need to write fewer than 100 lines of code and
make only minor configuration changes in order to get this to work.
It's a reasonable price to pay for the end result we
want. Because jPetStore and the Simple Spider were
designed to allow for extension in the first place, they fit together
well with minimal work.

Conversely, we could write much less code and in fact do almost no
work at all if we chose to connect to the Spider through the existing
web service interface rather than integrating it directly with the
jPetStore. Since the web service interface already
exists, it might be construed as a violation of the
"do one thing, and do it well"
principle to add another, seemingly useless interface. In this
instance, though, the added cost of sending a bloated message
(XML/SOAP) over a slow transport mechanism (HTTP) is too heavy,
especially given the minimal amount of work it will take to get a
faster, more efficient integration.


/ 111