There are several publications about patterns in j2me:
Architectural manifesto: The MVC design pattern in MIDP development by Mikko Kontio
Identification of Design Patterns for Mobile Services with J2ME by J. Narsoo and N. Mohamudally
Big designs for small devices by By Ben Hui
Patterns I use sometimes:
MVC - to separate UI from controller classes and data structures, may be useful for code reuse on different platforms
Command - to reuse code in user interaction and app work-flow
Interface - to simplify several components use (ex different types of connections or data storage) and component testing (see Blackberry - change latitude and longitude on the device to test app)
Also Observer may be used for UI update tasks(see sample with HttpRequest)
What are your favorite patterns in J2ME/BlackBerry?
How about using Singleton to handle settings/configurations.. and factory pattern to cover about UI theme (for example). I'm also still new in developing blackberry, I find it quite difficult to know which pattern is suitable for one conditions or another.
Related
I am new to opendaylight and I seek help regarding following:
How can I make two different applications communicate with each other?
Can I have something like a communication bus for my selected set of applications that can transfer data to each other? Or Do I need to have a single application with submodules (with different features ) to achieve the same task, i.e feature communication in this case.
The main feature that sets OpenDaylight (ODL) apart from other SDN controllers is the Model-Driven Service Abstraction Layer (MD-SAL), which provides a framework to share structured/modeled data and send notifications between ODL applications, among other things.
If you want to transfer data between ODL applications, you first need to model it using YANG, and include the YANG model in one of the applications.
To take advantage of the features offered by MD-SAL, please take a look at the official documentation. Once you understand the architecture, you should look at the source code of existing applications to see examples of how to take advantage of the power of MD-SAL.
Each Area will have its own config etc. So as the areas increases, the complexity and maintainability increases as well. Will it be good choice to modularise or partition and MVC application functionality in to Areas or continue with traditional Controller/View approach?.
Please suggest a common solution or better way to architect a large scale MVC application.
Areas shouldn't be confusing, and certainly aren't redundant. As you say, they allow you to partition your web app into smaller functional groupings. This is extremely helpful when the size of your applications grow and a single application umbrella becomes unwieldy.
As an example, I have just completed a large application that stored promotional data for various retailers across North America. The US and Canada sales teams are isolated, but are executing their tasks in nearly the same business contexts.
It made a lot of sense to partition the US and Canada parts of the web app into Areas, which organized things a lot better for us. Each area could still use the same components where they make sense (repositories, services, etc...), but the isolation Areas brought allowed us to build separate controllers and views specific to each business group, instead of trying to run a bunch of logic checks to accommodate whatever region the user was in.
Here is possible alternative to your approach from "Programming ASP.NET MVC 4" by Jess Chadwick, Todd Snyder, and Hrusikesh Panda:
There are many different approaches to take when designing an ASP.NET
MVC application. A developer can decide to keep all the application’s
components inside the website assembly, or separate components into
different assemblies. In most cases it’s a good idea to separate the
business and data access layers into different assemblies than the
website. This is typically done to better isolate the business model
from the UI and make it easier to write automated test that focuses on
the core application logic. In addition, using this approach makes it
possible to reuse the business and data access layers from other
applications (console applications, websites, web services, etc.).
A common root namespace (e.g., company.{ApplicationName}) should be
consistently used across all assemblies. Each assembly should have a
unique sub-namespace that matches the name of the assembly. Figure 5-4
shows the project structure of the Ebuy reference application. The
functionality for the application has been divided into three
projects: Ebuy.WebSite contains the view, controllers, and other
web-related files; Ebuy.Core contains the business model for the
application; and the CustomExtentions project contains the custom
extensions used by the application for model binding, routing, and
controllers. In addition, the project has two testing projects (not
shown): UnitTests and IntegrationTests.
There is no rule on whether to use Areas or not, it's basically up to solution architect to do an estimate should using areas provide benefit or not.
Our latest project that involved areas, included 3 different types of users working on the website. We used controller naming scheme where controller name matched the resource name (i.e. CategoryController).
However, certain resources could have been accessed by all 3 user groups in completely different manner: one user group could only list resource, other user group could manage them (basic crud) while the 3rd user group (admin-like) could do advanced features such as exporting, importing, etc...
By separating the functionalities in areas, we've reduced security problems by simply decorating the controller in area to request user type specific for that area, in order to avoid mixing of permissions. Doing it on the base controller for the area, made things even more centralized.
That is one reason why we would pick separation of areas.
On the other hand, we've often been in situation where we have request for a high-demanding public website and "back-office" internal configuration website. For the performance and scalability + concurrency issues, we've quite often designed public website that could be load balanced as a one project, and back-office website that would be only hosted once as a second project - instead of using areas.
Again, this is just one approach from the industry, not necessarily the optimal approach.
I'm building a rails application and I'm having trouble working out how create diagrams for the application architecture.
I've created UML class diagrams in the past, so consequently that's where I headed. I've found the railroady gem that generates UML class diagrams via a rake task, however it separates the models from the controllers - which feels fragmented to me.
What I want to know is whether there is another (preferably better) way to model an MVC (rails) web application.
I'm not necessarily looking for a gem to generate the diagram for me, I'm happy to create it manually in visio, I just don't know what type of diagram I should be using.
You may want to try the Robustness diagram, also sometimes called MVC diagram.
See for example here and there.
It is not really a UML diagram, but most UML tools manage it through stereotypes and custom icons. The tool I use, Magicdraw UML, uses a class diagram, but I think I heard of tools that use communication diagrams (not sure, though).
However, it may or may not meet your expectations, as it is a very global diagram.
There exist a metodology named UWA (Ubiquitous Web Application) that allows you to describe not only the data structure, but also the navigation, presentation and transaction models.
The UWA methodology has a user-centered approach, which improves the requirement and design definitions. Since this metodology was developed specifically for modelling web applications, it allows a clear separation of content, navigation, transaction, publishing and operational elements.
UWA begins with a goal-oriented requirements engineering that naturally arise to later design stages, revealing key features that should be implemented. This leads to reasoning about some requirements that might have not been identified beforehand, or may have been underrated.
You may find additional information about UWA here.
Even if you decide not to apply this methodology, it may provide you with some tips about adapting UML diagrams to web applications.
Have you ever come across a Use Case Diagram before? It's not strictly a diagram to outline a systems architecture, but it does provide a good visual representation of communication with other parts of the system/ external actors, during a given "use case" (or process).
For example:
User(Actor) --> Update Status(Use Case)--includes-->(Log in)
Here we have a user wanting to update their status. In order to do this, they need to be logged into the site (an included use case). Thinking about this in MVC mode, we know that "Update Status" and "Log in" would both be controller methods, which would both communicate with the attracted website database (also an actor), thus demonstrating the communication path within a system.
Actors of a system can be anything that communicates with the actual system during a process, usually externally, so users, browsers, database, clients etc.
In terms of modelling the MVC architecture, this is done best by the Class diagram, but a Use Case diagram would also aid in the visual representation.
I always draw up a Use Case and Class Diagram together before I start coding, as a way of extracting the system requirements and laying them out in a working design. UML diagrams are design tools after all- there's not really much point in creating one after you've written the system code!
Just something to think about anyway- hope this helps!
brief overview of basic use-case diagrams
I know that some website are applications, but not all websites are applications (albeit maybe just a brochure viewing site)
Is there an in depth dummy use case for a brochure type site which would be beneficial to use.
When it comes to a corporate front facing website for example I suffer from feature blindness, although for an actual database driven application (for example a purchase order system) I feel within my element.
Is there any resources that can help me view "brochure" sites in the same light than I do with a pro bono database driven applications.
This is really useful thread. I have always battled with use cases for brochure sites, despite totally espousing the use of UML... I often feel caught between UX agency outputs & trying to ensure the whole Requirements Spec ties together, especially when agencies tend not to use UML.
There are several use cases that do apply beyond view menu / view brochure page - site functionality like print page, search site etc, sometimes accept a cookie to view specific content - but not much on classic brochure-ware. (All that ties well into user journeys / personas without having to restate the UX deliverables)
However, once using a system eg a CMS to create the website content - then I think the use cases get properly useful (as per comments above), as there are not only (usually) several actors inc the system, but also varying cases per content type so you can reference those UX deliverables without duplication and start filling in the gaps, plus tie up content strategy type deliverables (eg workflow & governance) by looking into the business processes and the system / user interactions. At the end of the modelling & specifications, you can get useful test matrices this way; plus class diagrams that relate objects to taxonomies (more agency deliverables to tie together in Functional Rqmts / Specs stage).
That's the way I'm trying to tackle it these days.
Use Cases can be used to model requirements of a system. System is a structure with input and output mappings. So if you have a static web page, you cannot interact with it in a other way than to view it.
As discussed in comments, if you think you did not understood the goals of stakeholders (what that word document sent by your boss ment...), you have to ask more and find them, use cases are a good technique for this.
In a cycle, discover actors (systems and roles interacting with the system you have to develop) and use cases (what needs of those actors the developed system should ssatisfy). Every time you find an actor, you may ask what other needs (possible use cases) he has and when you find an use case, you should ask who will participate in it and who is interested in it (who is the next actor and who are the stakeholders). Then you can define the scope boundaries and prioritize...
This is a general question about design. What's the best way to communicate between your business layer and presentation layer? We currently have a object that get pass into our business layer and the services reads the info from the object and sets the result into the object. When the service are finish, we'll have a object populated with result from business layer and then the UI can display according to the result of the object.
Is this the best approach? What other approach are out there?
Domain Driven Design books (the quickly version is freely avaible here) can give you insights into this.
In a nutshell, they suggest the following approach: the model objects transverse from model tier to view tier seamlessly (this can be tricky if you are using static typed languages or different languages on clinet/server, but it is trivial on dynamic ones). Also, services should only be used to perform action that do not belong to the model objects themselves (or when you have an action that involves lots of model objects).
Also, business logic should be put into model tier (entities, services, values objects), in order to prevent the famous anemic domain model anti pattern.
This is another approach. If it suits you, it depends a lot on the team, how much was code written, how much test coverage you have, how long the project is, if your team is agile or not, and so on. Domain Driven Design quickly discusses it even further, and any decision would be far less risky if you at least skim over it first (getting the original book from Eric Evans will help if you choose to delve further).
We use a listener pattern, and have events in the business layer send information to the presentation layer.
It depends on your architecture.
Some people structure their code all in the same exe or dll and follow a standard n-tier architecture.
Others might split it out so that their services are all web services instead of just standard classes. The benefit to this is re-usable business logic installed in one place within your physical infrastructure. So single changes apply accross all applications.
Software as a service and cloud computing are becoming the platform where things are moving towards. Amazons Elastic cloud, Microsofts Azure and other cloud providers are all offering numerous services which may affect your decisions for architecture.
One I'm about to use is
Silverlight UI
WCF Services - business logic here
NHibernate data access
Sql Server Database
We're only going to allow the layers of the application to talk via interfaces so that we can progress upto Azure cloud services once it becomes more mature.