Embedding Perl in HTML with Mason Chapter 10: Scalable Design

Tham khảo tài liệu embedding perl in html with mason chapter 10: scalable design, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Embedding Perl in HTML with Mason Chapter 10: Scalable Design Chapter 10: Scalable DesignSo now that you know how to do things with Mason, its time to startthinking about how to do things cleanly, scalably, and maintainably. Masonis a good tool, but it is not magic, and you still need to think about designwhen you use it.Modules Versus ComponentsThis book was written before things like Catalyst, MasonX::WebApp andMasonX::Interp::WithCallbacks were available or widely used. The lattertwo modules were written to make it easier to move application logic out ofcomponents into modules.Catalyst is a full-featured framework which makes it easy to build a nicelyarchitected MVC web application. You can use Mason as the templatingpiece (the view) with Catalyst quite easily, and youre encouraged to check itout at http://catalyst.perl.org.Mason is a powerful tool for generating content. Its combination of easytemplating syntax, powerful component structures, and features likeautohandlers, dhandlers, and component inheritance all combine to make itmuch like Perl itself: it makes easy things easy, and difficult things possible.However, exactly like Perl itself, the facilities it provides can make it all tootempting to do things the easy way, and Mason makes no attempt to enforceany sort of discipline in your design. Instead, this is your responsibility as aprogrammer and application designer. This is where the responsibilityalways lies, no matter what language or tool you are using.Though Mason is at its core a text templating tool, it also provides muchmore functionality. One such piece of functionality is that individualcomponents are almost exactly like subroutines. They can be calledanywhere in your processing and they can, in turn, call other components,generate output, and/or return values to the caller. And, like Perlssubroutines, variables defined inside a component are lexically scoped tothat component.It is this similarity between components and subroutines that can lead todesign trouble. As long-time Mason users, we have come to believe thatMason components should be used almost exclusively for generating output.For data processing, we believe that Perl modules are the better solution. Inour experience, this division of labor leads to long-term benefits inmaintainability and clarity of design.When we say generating output, we mean generating binary or text outputof any sort (HTML, XML, plain text, images, etc.) to be sent somewhere(STDOUT, a web client, etc.). In a web environment, this includes thingslike sending redirect headers or custom error responses as well as HTML.When we say data processing, we mean the work of retrieving data froman external data source such as a database, processing data and constructinguseful objects or data structures, doing calculations, implementing businesslogic, or munging data.Our exception to this rule is when the data processing is entirely part of theUI that Mason is generating. For example, in a web context, it may benecessary to do some munging of POSTed data or to translate data from themanner in which it is presented in the UI to a format suitable for yourbackend.But Mason is not the right tool for all jobs, and it should not form the entireinfrastructure of any project.The rest of this discussion will assume a web environment, as that isMasons primary domain, though this discussion can apply to anyenvironment in which Mason could be used.Another important goal is to minimize duplication of code. You will nevereliminate this entirely, but this should always be your goal. Duplicated codeleads to bugs when one piece changes and the other doesnt, increases thedifficulty of understanding the entire code base, and increasesimplementation time for bug fixes and changes.Obviously, the line between generating output and data processing isextremely blurry. Given that fact, perhaps the best goal is to reduce the dataprocessing in Mason components to the minimal amount necessary toproperly generate output. All other application logic should be placed in Perlmodules and called from your components.The line that needs to be drawn is one that makes the code flow in both yourmodules and your components as natural as possible. We dont want to gointo impossible contortions in order to eliminate four lines of processingfrom a component, nor do we want to put knowledge about Mason or ourcomponents into our modules. Like all design tasks, there is as much art asskill involved.For example, as mentioned before, we consider it entirely appropriate forMason components to handle incoming request argument processing. Acomponent could use these arguments to determine what library function tocall or what object to instantiate. It might also use these arguments to changethe way it generates output, for example if there were a parameter indicatingt ...