tuzgai
Registration date:
Post count: 31
My name's Stuart and this is my personal blog, I'll be recording what I learn at the Software Guild here.
All Posts
Edit Profile

Posts from this user

Another update + dependency injection writing exercise

tuzgai posted at

Now that we've had some time back in the classroom I think the class is feeling a little better about things. It helps that the material this week is pretty light, so people have been able to focus on getting up to speed on their projects. I do have an anecdote to share:

Yesterday we were given a small group exercise where we used stream operations to determine whether a given hand of cards was a poker hand. We found the three of a kind pretty challenging, it didn't neatly fit into the methods we knew, even though we knew we could do it easily in a for loop. With my encouragement to not give up, we spent another 10-15 minutes reading up on the available stream operations and collectors and eventually found the groupingBy collector and worked out how to process the set it returned. I did this with a lot of hitting . in netbeans to look at options from the suggestions and googling javadocs.

At the end, one of the people in my group said "Huh, so research is really important?" and had an expression like he'd found a new superpower. It was really exciting to see that revelation and to help encourage him to not give up on problems but keep working away and researching solutions. I'm ahead in the class, so I'm glad that I can role model problem-solving techniques and help everyone push forward.

Anyway, here's my writing exercise on dependency injection:

Dependency injection is an encapsulation strategy that allows the various classes of a project to be initialized with their dependencies in the constructor with the parameters from an external source, rather than called directly from the class. This allows us to more easily manage dependencies and potentially swap them out as needed.

For example, when testing a component we can construct it with a stub dependency set up specifically for testing - this allows us to test our component independently of its dependencies. Another example is that we might want to develop our application with a simple file-based memory system and then switch to a database later. To achieve this, we will use the Spring framework's dependency injection capability. Essentially, we will declare all of our classes and the arguments to their constructors in an XML configuration file and call Spring to inject these dependencies into our app. This way, in our previous examples we can have a 'release' config, a 'testing' config and 'db' and 'file' configs rather than doing a bunch of work in code to manage these.

Last edited Permalink

Week 4 Update

tuzgai posted at

I'm starting to have more work to do in class and less time to blog, which is probably a good thing. But also, we've had sort of a weird week.

Last Tues-Thu were work from home days, as the weather in MN was far too cold for anyone to be outside. We had online meetings with our instructor twice each day, but much of the day was left for independent work (while the instructor was available via slack). While I personally have a lead and wasn't really hampered by the disruption, a number of my classmates are pretty worried that they didn't master the material on unit testing and the service layer as well as they might have otherwise.

To compound that, our instructor was out on planned leave again this Monday and we didn't get a sub. This means we had another day with more course material open to us but no instructor to help us review/work on the weekend project and another day of our precious 12 weeks mostly lost.

Tension was high in the classroom today! Most of the class is starting to fall behind and whether or not it had a big impact the number of disruptions giving people an excuse to point at is not helping them progress. Hopefully things will get back on course tomorrow. I do think that everyone has a good shot at success and as a class we're not as far behind as we feel, based on the new material that was just opened up.

But! I hear some people still haven't finished their week 1 and week 2 projects and worry that they're just not going to be in a position to finish the first 6 weeks in time to start the second 6 weeks. In the meantime I'll just keep doing my best to stay ahead and help my classmates if they have questions.

Last edited Permalink

Writing exercise: MVC

tuzgai posted at

As you might have noticed from my earlier posts, I had a headstart on this writing exercise.

The model-view-controller (MVC) pattern is a design patterns popular for managing CRUD (create-read-update-delete) applications. That is to say, it is useful for projects that involve viewing, editing and storing data. MVC allows for a clear *separation of concerns*. Each component handles just one category of task, which means that each layer can be coded and edited separately.

- The model consists of a number of data access objects (DAOs) and data transfer objects (DTOs). It is concerned entirely with storing and accessing data, whether it be just to internal memory or storage. The DTO is used to expose this data to the rest of the application, all layers can access it.

- The view handles user interface and nothing else. If the application needs to display information to the user or collect information from them, the view layer takes care of it.

- The controller is the brains of the operation, it directs program and data flow between the view and model. Where the view displays things and the model stores them, the controller says what to display and when to store things. Frequently in Java the view and model layers will be abstracted for the controller through interfaces.

This means that you can design your controller, model and view independently and as long as the model and view obey their respective interfaces, everything should work. This loose coupling is very useful when scaling your application, as many team members may be interacting with each layer and having everything mixed together would quickly become untenable.

While this pattern is useful for CRUD applications, it encounters limitations when you need to apply business logic to its interaction, as this logic doesn't cleanly fit into the model, view or controller. To support this logic, we use a service layer that sits between the model and controller. The service layer handles logic like validation of input data - when there's a service layer, the controller interacts with it instead of directly with the DAO. MVC is just one design pattern, but since most web applications are essentially about handling and displaying data it is very popular for that purpose. Most web frameworks are based on a variation of the MVC pattern.

Last edited Permalink

Day 10 Service Layer

tuzgai posted at

For our weekend project we re-implemented the code-along with a little extra - an edit feature. The project was to implement a text-based DVD collection that would add, remove, edit and store to a file (aka a CRUD app) using the MVC pattern. I'm pretty happy with how mine turned out - I made an extra little menu to display the data to be edited with options for how to edit it. My code review went well, I wasn't given any changes to make.

Service Layer For a CRUD (create, read, update, delete) app that just manages data, the MVC pattern works quite well. We have a dumb DAO that just manages data, a smart controller that runs the show and a UI that UIs. Many applications have more than just CRUD functionality through, they may need to apply business logic such as "no duplicates" or "give the 100th user a prize".

For this, where does the logic fit? Obviously not the UI. It sounds like too much work for the controller, which is supposed to just manage and not do work. Similarly the DAO is supposed to be dumb and fast, it shouldn't be doing all this logic. Enter the service layer. This new layer sits between the controller and the DAO to apply business logic.

With a service layer, the controller no longer has access to the DAO, it instead makes similar calls to the service layer. An important service layer tool is the service layer exception. These operate just like other exceptions, but let the controller know that there was a problem with the business logic of the proposed operation rather than a direct data problem or another runtime exception. The service layer can also do other validation, logging, etc functions. Anything that feels like it doesn't fit in the MVC layers probably fits in the service layer. To make this happen, the service layer frequently will interact with more than one DAO.

Last edited Permalink

Day 8 MVC

tuzgai posted at

The model-view-controller pattern (MVC) is a common design pattern for systems with data and UI like web sites. The goal is a clear separation of concerns in the areas of the program's operation. The model can just care about data, the view just about user interaction and the controller ties it together. There are a number of elements to this pattern:

1. Model - manages the data - DAO - data access object, this manages the actual storage and internal representation of the data - DTO - data transfer object, this is the commonly available data object - both the view and model can use this.

2. View - manages user experience. Can display data view calls to DTO.

3. Controller - manages program behavior, actually calls the model and view functions to make things happen. The basic process to build an MVC application is to block out the interaction model with dummy functions for testting, then set up the data representation, then start implementing user interactions, one by one.

When we start implementing user stories, we will follow this cycle:

1. Update the model to implement the desired interaction.

2. Implement view functions to display the interaction.

3. Update the controller to call these new model and view functions and apply the interaction. A useful thing to do is define interfaces for the DAO and UI functionality. This will allow you to create multiple implementations such as changing your DAO to use databases instead of files and then choose the configuration you'd like.

We can achieve this through dependency injection - essentially, we can create an overall 'app' class to wire things together and pass the desired implementations into the constructors for our other classes. We had an 11 part code-along covering building a small class roster app with this model. It's a lot of work for small projects, but I can see how it would scale. Also, now I can see how the Flask project this blog was based on essentially used this model.

Last edited Permalink
Newer Posts Older Posts