Contents tagged with Design
-
Use Extension method to write cleaner code
This blog post will show you step by step to refactoring some code to be more readable (at least what I think). Patrik Löwnedahl gave me some of the ideas when we where talking about making code much cleaner.
-
Aspen – A sample app using Silverlight 4 and .Net 4.0 – part 4 of X – DomainService, using DTO and Unity
Note: The code in this post is based on the VS 2010 Beta 2, and changes can be made until it hits RTM.
-
Aspen – A sample app using Silverlight 4 and .Net 4.0 – part 3 of X – Repository implementation
Note: The example code in this blog post is based on the VS2010 Beta 2, changes can be made until VS2010 hits RTM.
-
Distributing domain entities over the wire
When we design our domain entities we don’t have a presentation layer or database in mind. The domain entities are core business objects located on the server or client side based of what kind of application we are building. Domain entities aren’t designed for distribution. When we realize that we need a distribution, we shouldn’t distribute the entities, instead collect the data we need to distribute and create a data transfer object (DTO) instead. Have the network in mind, a domain entity aren’t designed with a network in mind and of that reason not suitable for distribution. When we create our domain entities, they aren’t designed for presentation purpose, they are designed to fulfill business needs. You should be careful when you start thinking about returning a domain entity to the View when using a patterns like MVC, instead use DTO or a ViewModel, because once again the domain entities aren’t designed with presentation in mind, and aren’t often suitable for presentation purpose. It’s often better to map them to a DTO or ViewModel, objects that are suitable for presentation purpose or passed over the wire.
-
RIA Architecture with Silverlight in mind
Rich Internet Application (RIA) is an interesting topic. More and more business apps are moving into to the cloud, and more and more will have better User Experience (Ux). According to Gartner Research, nearly 60 percent of all new application development will include RIA technology by 2010. Today we can use different technologies to build a RIA, for example, AJAX, Flash and Silverlight etc. When it comes to AJAX we will soon reach the top of what we can do with it, because of the limitation of HTML, Client-side scripts and the browsers etc. That makes Silverlight and Flash more interesting regarding to me. But what is RIA? RIA It’s an internet applications that looks and feels like desktop applications, it also provide most of the maintainability and deployment benefits of Web applications. A RIA client can have state, so to increase User Experience, the user can work with data for a while until it will be passed down to the server for processing. Because the client side of a RIA can have state and work with data for a while, it’s extra important to have concurrency in mind. Some other users can have changed the data during the time we have worked with our copy. When developing RIA Clients we need to have several things in mind, for example a RIA is often running within an execution container in the Browser, so people can hit the refresh button or use the back and forward buttons, which can be reload the whole app and the current state can be gone. When we creates a large RIA, we can’t let users wait for hours until the application is loaded and started, so we need to load views etc on demand, and split them into small “modules”. Developing a RIA is not like developing a stateless ASP.NET app.
-
Isn't it boring to write crosscutting concerns?
To make sure we have clean code and make it easy for us to maintain, we should try to be lazy and reuse code as much as possible, we should also avoid redundant code. But when it comes to crosscutting concerns, we have to be redundant, or? What code is mostly redundant in our code? I will assume that code to check security and logging exceptions are the most redundant code we write. A method should only do one thing, but we can't skip crosscutting concerns, we need it. So basically several method will do more than one thing. Wouldn't it be much better if we only focus on the core concern and skip the crosscutting concerns when we write our code? How can we skip the crosscutting concerns but still has it? The answer is Aspect Oriented Programming (AOP). The PAG team has a Policy Injection Application BLock (PIAB) which we can use to intercept our crosscutting concerns into our code, we also have Spring.Net and some other frameworks. By using AOP frameworks we don't need to write the same code for logging exception etc over and over again, we will also have a much cleaner code, and our focus will only be the core concern. Oh, I feel so lazy, but why should I spend time to write code that do the same thing over and over again, it's so boring, isn't it :P Are you tired of writing crosscutting concerns over and over again, and do you use AOP today?
-
Returning IQueryable<T>
Since LINQ was added to the .Net Community as a new wonderful new player, more and more solutions I have seen returns the IQueryable<T> from the Data Access Layer. One reason is to easy create different kind of queries in an easy way and execute them. Some developers use the IQueryable<T> interface to create a light weight interface for the Data Access Layer. It's an interesting solution, but at the moment I don't like it.
-
Using Web Services in a 3-tier architecture
During the age of the Windows DNA, most of us developers used COM/COM+ and a 3-tier architecture. Where we separate concerns by placing the views to present data into a layer called PL (Presentation Layer), we add all business logic into one single layer called BLL (Business Logic Layer), all code that handle data access was also placed into its own layer called DAL (Data Access Layer). During this time when Windows DNA was a hot topic, most application used this architecture.
By using DCOM it was easy to distribute the different components in the layers into distinct tiers. DCOM had its advantage and also disadvantage (DCOM hides the "distribution" and distribution could be done after application was written without the developers awareness, most applications wasn't designed for distribution purpose.). There was few application I was involved with that used DCOM, and I will in this article focus on the application that didn't use DCOM. The 3-tier architecture was well defined and common used. Several applications today used this architecture. When .Net arrived several developers was scratching their heads, it was a whole new platform for most of them and a difficult and confused time began, "how should this 3-tier architecture be applied on the .Net platform?". Web Services was introduced somewhere around this time and that was a bright light for some solution architects and developers, now they understand how to apply the 3-tier architecture on the .Net platform, the answer was to replace COM/COM+ components with Web Services. So instead of using a binary standard for the communication, XML and HTTP was used. -
Map Objects to one Object
In my previous post I wrote about how we could use Dynamic Compilation for mapping object to object in a configuration file, mosly for fun to simply try something different. I spend a few minutes to see if I could do something more with it. It ended up that I can use it to several things, like creating Factories, or send in different kind of objects and map several into one. Here is how I for example can send in more domain object to map them into a PresentationCustomer:
-
What do you think about using a presentation model for presenting your domain model?
