Brand new SmileTable object oriented architecture

Like I mentioned in the last post I have decided that I want to change SmileTable architecture from service oriented to object oriented architecture. I also explained why I am doing this. I feel need to introduce my new application structure so in this post I want to do It.

Like i mentioned I have created object oriented aplications already so I feel more better and comfortable than in service oriented archtecture.

In SmileTable Solution I have five projects

ST solution

Let’s start from describe SmileTable.DataAccess project

ST dataaccess

SmileTable.DataAccess project is a class library which provide access data for application. I have there three forlders. DataContext is a place where I keep application database context.
I am using EF and code first approach so I map entities to database tables there and also I configure EF in overrided OnModelCreatingMethod. Migrations folder is folder created by EF. This folder is allways creating after new migration. We have to create migrations because If we change our model for example by adding new property to entity class (what may be equal a new table row) we need to update database. To do that we have to enable migrations, add new migration and update database. This all happens in Package Manager Console. It’s a quite simple and I like It. Of course EF help us „If something is no YES 😛 „. After add new migration we can allways see what exactlyis up and what is down. We just need to open that class migration. Migrations allow us to back to the selected migration in easy way. So I think It is very helpfull for maintenance application. In Repositories folder I have repositories for each of entity. Like we see I also have BaseRepository class. Every single repository is generic repository inheriting from BaseRepository. I am doing that because there is no neccessery to duplicate methods which will be the same for all repositories.

ST domain
SmileTable.Domain project is the place where I keep Entities which for me are just DTO so I am no so sure is Entity word good in this case.
That classes we know from post about SmileTable service oriented architecture and there is no need to introduce them. In RepositoriesContracts folder I just keep contract for every single repository. I need contracts because I use Dependency Injection and of course we should create interfece because one of SOLID principle (Dependency Inversion Principle) says that is good practice to „program to interface not to an implementation”  It gives up several advantages and helps create good application architecture.


ST infrastructure SmileTable.Infrastructure project is a place where I keep Controller Factory for my Dependency Injection. Controller Factory Is the place where I bind my interfaces to concrete implementations. I think It is very interesiting topic and for sure I will focus on DI in another psot. In SmileTable I use ASP.NET Identity authentication and I would like to move that logic to SmileTable Infrastructure project. SmileTable.Test project is place for unit tests which are very important. I have didn’t understand unit tests a long time I mean why we are using them what is the purpose of them, and why the hell I have to waste time for It. Now I see why unit tests are so important and I want to create them for SmileTable application for sure!!!

The last project is SmileTable.WebUI which is of course ASP.NET MVC 5 application and there is no need to introduce them



Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:


Komentujesz korzystając z konta Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s