.Net template solution architecture

692 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
692
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

.Net template solution architecture

  1. 1. .Net Template Solution Diogo Cunha
  2. 2. Architecture should be• Flexible to change, add and remove features• Maintanable for many developers with different coding habits• Sustainable for growth• Understandable for code review and optimization• Easy to add new features with few lines of code without losing structure• Testable (unit and integration) http://pt.linkedin.com/in/diogogcunha/ 2
  3. 3. Solution Layers dependency proj.Frontend proj.Services proj.Data http://pt.linkedin.com/in/diogogcunha/ 3
  4. 4. Data LayerprojName.Data.dllThis layer would be a new Project inside the solution and it is an abstraction for the datathat the system writes and reads from different data sources. It should only contain CRUDlogic and nothing else.Repositories and entity objects should be here. proj.Data http://pt.linkedin.com/in/diogogcunha/ 4
  5. 5. Entities/DTOsprojName.Data.Entities• Entities are the raw domain objects that come from the data source. So if you areintegrating with and external platform such as Facebook or if you are writing on a XMLyou should have that information in object classes so you have strongly typed entities.• A lot of .Net developers will use EntityFramework to do most of the work writing to thedatabase. Using model first this is the place to put the .edmx file, using code first this iswhere you’ll put your DbContext file and your entities.• In order to be able to mock the DbContext or the ObjectContext you should do awrapper around it (or a partial class) use an interface and expose what you need.• Avoid unecessary dependecies using different projects under the same namespace. UserEntity FileEntity PostEntity UserRepository FileRepository FacebookPostRepository UserEntity FileEntity PostEntity 5 projName.Data.dll projName.Data.Facebook.dll
  6. 6. Repositories projName.Data.Repositories• Each entity should have it’s own repository. If the entity is read only so should be therepository.• All repositories must have their own interface and it might be useful to have abstractrepositories to decrease the amount of code to be written.• Repository methods should be easily overriden for flexibility so we could make themvirtual but it’s not mandatory because C# let’s you override a method with the [new]word on the function signature.abstract class BaseRepository : IBaseRepositoryabstract class ReadRepository<T> : BaseRepository, IReadRepository<T>abstract class WriteRepository<T> : ReadRepository<T>, IWriteRepository<T>WritableEntityRepository : WriteRepository<WritableEntity>, IWritableEntityRepositoryReadOnlyEntityRepository : ReadRepository<ReadOnlyEntity>, IReadOnlyEntityRepository http://pt.linkedin.com/in/diogogcunha/ 6
  7. 7. Repositories projName.Data.Repositories.ReadRepository• Read repository is probably the most used one, so we should try to make it as powerfullas possible. Also because LINQ is cool I’m copying some of it’s namings.public interface IReadRepository<T> where T : class { T FirstOrDefault(Expression<Func<T, bool>> predicate); IEnumerable<T> GetAll(Expression<Func<T, bool>> predicate); IEnumerable<T> GetAll(Expression<Func<T, bool>> predicate, Expression<Func<T, object>> orderBy, bool descending = false); int Count(Expression<Func<T, bool>> predicate); bool Any(Expression<Func<T, bool>> predicate);} http://pt.linkedin.com/in/diogogcunha/ 7
  8. 8. Repositories projName.Data.Repositories.WriteRepository• Creating and updating entities is usualy a fairly simple operation and it should remainso. No other kind of logic should be implemented in these classes except default valueslike , for instance a CreationDate = DateTime.Now;• In some situations the Update method is not necessary (if you use EntityFramework forsome of your data) so don’t feel that obligated to implement this method, just leave thepossibility there for other data sources that might need it.public interface IWriteRepository<T> where T : class { T Add(T entity); T Update(T entity); T Remove(T entity);} http://pt.linkedin.com/in/diogogcunha/ 8
  9. 9. Services Layer projName.Services.dll • This layer would be a new Project inside the solution that references the Data project and it is where all the business logic should be centralized. • Services should be divided by actions oriented and also reading services or writing services, this will allow all writing services to be dependent on their corresponding reading services if needed (example: instead of a UserService use UserInfoService, UserEditService and UserAuthService) • External modules should be added to avoid unwanted dependencies to the main .dll file Services ProductServices UserServices Services.HttpServicesgetProductDiscount() addLoginCount() ProductEditService UserEditService UserSessionService ProductInfoService UserInfoService projName.Services.HttpServices.dll getUser() dependent on System.Web 9
  10. 10. Services Layer projName.Servicespublic class UserInfoService : UnitOfWorkService, IUserInfoService { public UserInfoService(IUnitOfWork unitOfWork) : base(unitOfWork) { }}public class UserEditService : UnitOfWorkService, IUserInfoService { IUserInfoService UserInfoService { get; set; } public UserEditService(IUnitOfWork unitOfWork, IUserInfoService userInfoSvc) : base(unitOfWork) { UserInfoService = userInfoSvc; }}public class UserSessionService : BaseService, IUserSessionService { IUserInfoService UserInfoService { get; set; } IUserEditService UserEditService { get; set; } public UserSessionService(IUserInfoService userInfoSvc, IUserEditService userEditSvc) { UserEditService = userEditService; UserInfoService = userInfoService; }} http://pt.linkedin.com/in/diogogcunha/ 10
  11. 11. Services Layer and Data Layer projName.Data.UnitOfWork.dll• A service will use the Unit of Work to access the data layer (the Unit of Work pattern is aclass that has a reference to all the repositories and to the context in which theserepositories work giving only access to the repositories and a SaveChanges method thatcommits the changes to the database). This doesn’t need to be a separate Project.• This should be implemented on a different Project so that when you reference theServices on the Frontend you don’t have access to the Unit of Work.//namespace projName.Servicesabstract class UnitOfWorkService : BaseService, IUnitOfWorkService { private IUnitOfWork UnitOfWork { get; set; } public UnitOfWorkService(IUnitOfWork unitOfWork){ UnitOfWork = unitOfWork; }}//namespace projName.Data.UnitOfWorkpublic interface IUnitOfWork { void SaveChanges(); public IUserRepository UserRepository { get; set; } public IProductsRepository ProductsRepository { get; set; }} http://pt.linkedin.com/in/diogogcunha/ 11
  12. 12. Mapping Entity <-> ViewModel projName.Services.Mappings• This is probably the most boring code to write because it’s simply transforming oneobject to another one, so I usually use AutoMapper which is a very handy tool.• There are several ways to do these mappings and I believe that the big concern here isperformance and easily understand to which ViewModels does a Entity map to and howthat mapping is processed, and the other way arround. UserEntity UserViewModel -ID -UserIdentityViewModel -Username -ID -Username -FirstName -LastName Mapping engine -Email -Email -UserInfoViewModel -Gender -FirstName -CreationDate -LastName -Gender http://pt.linkedin.com/in/diogogcunha/ 12
  13. 13. ViewModels projName.ViewModels.dll• The view models should be another Project in the solution to be referenced by theservices and Frontend.• Services only receive and return ViewModel objects that should have Frontend needs inmind and not domain entities to make them aligned with the operations they refer to.• Dividing the ViewModels into folders according to the entities they refer to will makethe code more maintainable. FrontendView ViewModels Services Models http://pt.linkedin.com/in/diogogcunha/ 13
  14. 14. Inversion of Control projName.IoC.dll• A separate Project should be made for the IoC (even if it only has one file with all theclass registrations) because it must reference the Services Layer and the Data Layer.• Inversion of Control pattern can save you a lot of code lines, help you keep thingsmodular and improve performance.• It’s not mandatory to use it for this architecture to work but it is as advantage.• We can initialize a service in 3 different ways with this architecture:public class UserController : Controller { private IUserInfoService _userInfoService { get; set; } public UserInfoService(IUserInfoService userInfoService) {_userInfoService = userInfoservice;//with Dependency Injection_userInfoService = new UserInfoService(IoC.Locator<IUnitOfWork>());//with Locator_userInfoService = new UserInfoService(new UnitOfWork());//NO IoC }} http://pt.linkedin.com/in/diogogcunha/ 14
  15. 15. Frontend layer projName.Frontend.dll• Frontend layer is where your services actually get exposed in whatever way you want.• It should be as easy to use a MVC.Net project on top of this architecture as it would beto use WebForms, WinForms or a Mobile App. Services http://pt.linkedin.com/in/diogogcunha/ 15

×