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

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

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

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

Justin Gehtland; Bruce A. Tate

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

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

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








4.1 Benefits of Transparency


For most of this chapter, I'm going

to
explore the relationship between a service and a model. Your ultimate
goal is to build a layer that's completely
independent from the services that it uses. In particular, you want
to keep all peripheral systems out of the domain
modelpersistence, transactions, securityeverything. Why
should the business domain model get such special treatment?

Business models tend


to
change rapidly. Transparency lets you limit the changes to business
logic.

With transparency, you can limit changes to other parts of the system
when your model changes.

You can understand and maintain transparent models much more quickly
than solutions with tighter coupling.

By separating concerns of your layers, you can focus business,
persistence, and security experts in the areas that make them the
most productive.


You can also build completely generic services that know nothing in
advance about the structure of your model. For example, a persistence
service can save any generic Java object; a security service needs no
additional code, but is based on configuration instead; a
façade gets the capability to make a series of steps
transactional just by adding a POJO to a container; a serialization
service can turn any object into XML without knowing its structure in
advance.

The core techniques in this chapterreflection, code injection
and other code generatorspack a punch, but they also add
complexity and weight to your applications. My hope is that with a
little supporting theory on your side, you'll be
able to use these techniques to pry that ring out of your hand.

To be sure, none of these ideas are new, but I don't
believe that they've received the weight that they
deserve in the Java mainstream. I'll first talk
about moving the control centers of the application to the
appropriate place. Then, I'll give an overview of
the tools that limit transparency, and wrap up with a few recommended
tools to achieve it: code generation, reflection, and byte code
enhancement, with an emphasis on reflection. If
you're not used to coding this way,
you'll find that it's going to warp
your mind a little. Take heart. You've probably seen
these techniques before, though you may need to rearrange the ideas a
little. In the end, you'll find the ideas that
percolated in the center of Smalltalk and around
Java's perimeter have the power that you want, and
even need.


/ 111