Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Within a single project solution introducing Areas when you have a lot of controllers does improve separation and allows modules to easily be copied in or out of the solution. However in a large enterprise solution I would favour splitting the logic into separate projects instead.
Thus having separate UI, Controller, SOA, Model and Repository projects. In this scenario Areas don't make sense any more, plus they add an extra top level to the Url which is often not needed, although I believe you can omit the area in the Url if you keep your controllers unique, but isn't that a bit smelly?
Perhaps Areas are good for medium complexity sites or when module code is better kept in one location so it can be copied to other sites or removed.
I'm not sure if that's the right question. Areas can be overkill for small projects, but it's hard to imagine a non-trivially large project not using areas to help keep classes organized.
I use MVC Areas for the enterprise and love several things about it:
Typically people are working on a feature within a given domain (e.g., Search, Checkout, etc). If the area names correspond with your business domains, MVC Areas help reduce the time it takes to implement a feature, because the related classes are easy to find.
MVC routing gives you a ton of flexibility over how how structure the URLs. I used to use the Action Controller "pattern" but for non-public facing URLs I've just fully embraced the Area default route to make things easy.
Areas give you the distinct advantage of styling and, more importantly, encapsulating behavior at a site-section level. Each area gets its own web config where you can control the base view page or add managed handlers.
You're absolutely right that services should be in separate projects / solutions altogether, that abstract the data access via repositories, in an environment where multiple clients can access common business functionality.
But MVC Areas are great at providing some order to the UI / routing chaos as a web project grows, which, to me, is invaluable, regardless of context.
First, before I answer note that this is just my opinion and it's mainly about models.
The way I see it, areas can be just so evil.. If you have many areas your solution explorer becomes a maze, and it can get so hard to find something.
I suggest creating a new library project inside your solution, and put the logic in there.
The best benefit (and it's not that you can find what you're looking for much easier) is that your application becomes much more modular. If you create a library and specify a reference for it in your ASP.NET MVC application, you can't easily make a mistake and involve UI in the logic.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am the lone developer on a new ASP.NET MVC project, so my ability to discuss design with peers is limited. I'd like to ensure that any change to my app in the future is confined to the layer being changed, so that the whole app doesn't have to change at once.
I'm planning to have 3 layers, each in it's own project, consisting of data layer, service/business layer, and presentation layer.
My data layer will use Entity Framework with a generic repository. This layer will return Entity types from the repo methods.
My service/business layer will be thin, but I wanted a nice separate place for business logic down the road. In the beginning, it will be nothing more than service classes for each of the major areas of my app. ie EmployeeService provides CRUD methods related to Employees that call upon the data layer. At some point, I may replace it with a Web API service layer and serve many clients.
My presentation layer will be ASP.NET MVC, with ViewModels and strongly typed views. Down the road, there may be additional clients.
I'm most interested in the communication between layers and project structure. My initial thoughts were to map data layer Entities to service layer Business Objs/Domain Objs or DTOs using AutoMapper, then mapping again to ViewModels in presentation. The mappings in the beginning would be mostly 1:1 though, so it feels redundant.
Is it a violation of DRY to have a DTO that is the same as the Entity class? That's the only way I know how to decouple from my database structure. Ideally, if I make a database change, I want to only have to change the Entities and the mappings. ie, I totally rearrange how I'm storing something and I have all new entity classes/relationships... I'd like to map the new data implementation back to the same DTO and higher layers never know.
The same repetition feeling comes up when mapping from service layer to presentation layer. My DTOs will get mapped to ViewModels. It's mostly the same stuff, but my thinking was that ViewModels also contain UI implementation details like sort fields and UI specific types like SelectListItem.
So is this actually repetition or does it just feel repetitive? Is there another way to accomplish my aim of isolating changes in layers? I'd like to be able to change or replace presentation, service or data layer with relative ease.
I recommend finding a solid (and SOLID) open source MVC project and follow that pattern. No need to re-invent the wheel -- .NET MVC is robust and there are plenty of projects that follow SOLID principles.
Take a look at NopCommerce, you can get the source code and you will see a well-architected app that answers many of your questions
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Can someone please explain or point out what are the most common design patterns being used or comes naturally in building a rails app (ie: simple apps with crud and search functionality)?
I mean, Ive been programming in java and used frameworks such as struts, and I was able to apply and identify software patterns such as in creational, structural, and behavioral.
Since I switched to ruby on rails, Ive been trying to understand how can I apply design patterns here....
please explain or point out what are the most common design patterns being used or comes naturally in building a rails app
I'm going to start by pointing out the obvious. What comes naturally is the MVC pattern, around which Ruby on Rails is built.
Other than that, Rails does not enforce any particular design patterns, and actually a common beginner mistake is to clutter your views, controllers and models with a multitude of responsibilities, trying to fit everything into the (very limited) MVC universe.
(This also seems to affect the way we write Gems for Rails, as many popular choices tack on to, and adds DSLs your controllers or models.)
That doesn't mean you are restricted to using just models, views and controllers, however. Anything you can do in Ruby, you can also do in Rails.
The popular use of ActiveRecord with Rails will usually prevent you from having a rich domain model, which can, in turn, limit the number of applicable patterns. In particular when working with your models.
Commonly, you will see a rich taxonomy of simple supporting objects, like service objects, form objects, query objects, policy objects, value objects, etc. All used to encapsulate some perticular behaviour of your application. These objects can implement patterns on their own (for example a decorator object implementing the decorator pattern) or be arranged to form common patterns.
For a simple application, this might be all you need--but you can, and should, make use of design patterns where it makes sense in your Rails application.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need some help in making a design choice for my application. It’s a fairly straightforward web application, definitely not enterprise class or enterprise-anything.
The architecture is standard MVC 5 / EF 6 / C# ASP.NET, and the pages talk to a back-end database that’s in SQL server, and all the tables have corresponding entity objects generated from VS 2013 using the EF designer and I don’t see that changing anytime in the near future. Therefore creating super abstract “what if my database changes” etc. separations is possibly pointless. I am a one-man operation so we're not talking huge teams etc.
What I want is a clean way to do CRUD and query operations on my database, using DbContext and LINQ operations – but I’m not good with database related code design. Here are my approaches
1. Static class with methods - Should I create a static class (my DAL) that holds my datacontext and then provide functions that controllers can call directly
e.g. MyStaticDBLib.GetCustomerById(id)
but this poses problems when we try to update records from disconnected instances (i.e. I create an object that from a JSON response and need to ‘update’ my table). The good thing is I can centralize my operations in a Lib or DAL file. This is also quickly getting complicated and messy, because I can’t create methods for every scenario so I end up with bits of LINQ code in my controllers, and bits handled by these LIB methods
2. Class with context, held in a singleton, and called from controller
MyContext _cx = MyStaticDBLib.GetMyContext(“sessionKey”);
var xx = cx.MyTable.Find(id) ; //and other LINQ operations
This feels a bit messy as my data query code is in my controllers now but at least I have clean context for each session. The other thinking here is LINQ-to-SQL already abstracts the data layer to some extent as long as the entities remain the same (the actual store can change), so why not just do this?
3. Use a generic repository and unitofwork pattern – now we’re getting fancy. I’ve read a bit about this pattern, and there’s so many different advises, including some strongly suggesting that EF6 already builds the repository into its context therefore this is overkill etc. It does feel overkill but need someone here to tell me that given my context
4. Something else? Some other clean way of handling basic database/CRUD
Right now I have the library type approach (1. above) and it's getting increasingly messy. I've read many articles and I'm struggling as there's so many different approaches, but I hope the context I've given can elicit a few responses as to what approach may suit me. I need to keep it simple, and I'm a one-man-operation for the near future.
Absolutely not #1. The context is not thread safe and you certainly wouldn't want it as a static var in a static class. You're just asking for your application to explode.
Option 2 is workable as long as you ensure that your singleton is thread-safe. In other words, it'd be a singleton per-thread, not for the entire application. Otherwise, the same problems with #1 apply.
Option 3 is typical but short-sighted. The repository/unit of work patterns are pretty much replaced by having an ORM. Wrapping Entity Framework in another layer like this only removes many of the benefits of working with Entity Framework while simultaneously increasing the friction involved in developing your application. In other words, it's a lose-lose and completely unnecessary.
So, I'll go with #4. If the app is simple enough, just use your context directly. Employ a DI container to inject your context into the controller and make it request-scoped (new context per request). If the application gets more complicated or you just really, really don't care for having a dependency on Entity Framework, then apply a service pattern, where you expose endpoints for specific datasets your application needs. Inject your context into the service class(es) and then inject your service(s) into your controllers. Hint: your service endpoints should return fully-formed data that has been completely queried from the database (i.e. return lists and similar enumerables, not queryables).
While Chris's answer is a valid approach, another option is to use a very simple concrete repository/service façade. This is where you put all your data access code behind an interface layer, like IUserRepository.GetUsers(), and then in this code you have all your Entity Framework code.
The value here is separation of concerns, added testability (although EF6+ now allows mocking directly, so that's less of an issue) and more importantly, should you decide someday to change your database code, it's all in one place... Without a huge amount of overhead.
It's also a breeze to inject via dependency injection.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I want to break our RoR website into different sections\domain, for the people working on each section can independently release there code.
Think of it as https://www.yahoo.com/
The main website has link to sub-domains
https://finance.yahoo.com/
https://waether.yahoo.com/
https://sports.yahoo.com/
Each team works on it's own section, and does independent releases.
I have tons of common code\configurations, that each section would need. So I'm hoping that I can create a main website that is a template of some sort, and is configurable. Teams that plug in there section when they are ready. And after that can manage their own releasing with need much help from us.
You might want to look into Rails Engines as an alternative to subdomains. Engines let you "mount" one (or more) Rails applications into a main "host" application. This makes it trivial to share code and configuration between the applications, but it does couple things more tightly.
How "separate" do you want things? The subdomain approach lends itself well to decentralization. You can have completely separate infrastructure for each subdomain; only sharing the parts that make sense. Engines provide a half-way option that lets you develop each piece independently, then deploy and manage a single application in production.
If you want to share stuff (code, infrastructure, etc), both options will require careful coordination and testing when it comes to deployment.
Separate sites are generally separate projects. If you have shared infrastructure or configuration you might be able to share that via a private gem, a shared database, or a centralized service of some kind, depending on your needs.
Depending on how big or diverse you expect your various sub-projects to be, it may not make sense to put them all in one place.
I guess I would ask, do my apps actually need to depend on one another? If not, and they're mostly just sharing code/configuration, then that problem has already been solved via shared libraries and databases for config data. I don't see why you would need to manage the project as one thing (especially in terms of source control, etc.) if the separate parts do distinct and separate jobs.
This largely depends on what differences you will see between the various subdomains.
If it is only written content, styles, etc. you may want to consider a CMS solution such as Refinery CMS (http://refinerycms.com) which is open-source and can be customised if you require.
If you are thinking that each subdomain will have different code, tests and deployment schedules then this will quickly become a nightmare. In that case I would suggest you write common code modules for the functionality that is shared between the domains, and then have each subdomain as a separate rails project and app that references the common code.
Edit: Thinking about it further, you will find either initially or over time that the various subdomains will diverge as they have different use cases, business rules and requirements. Putting the shared code into a library or gem that each project can reference will give you the flexibility to create and update the common code separately while leaving each individual domain to implement their own custom logic - imagine if you needed to update your if rules and case logic every time the subdomains had a new requirement
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
First, I apologize for the open-ended nature of this question. However, I've been paralyzed by this for months, and in spite of consent searching, still cannot get past this.
I have been working on an MVC/EF app for a while. I'm trying to get an understanding on how to design and build a testable MVC3 application backed by Entity Framework (4.1). You can see a few questions I've asked on the subject here, here, and here.
I'm trying not to over complicate it, but I want it to be a sound, loosely coupled design that can grow. The way I understand it, the following are pretty much bare minimum required components:
MVC app
This is very thin. As little logic as possible goes here. My views have as little conditional logic as possible, my view models are never more than POCOs, and my controllers simply handle the mapping between the view models and domain models, and calling out to services.
Service layer + interfaces (separate assemblies)
This is where all of my business logic goes. The goal of this is to be able to slap any thin client (forms app, mobile app, web service) on top of this to expose the guts of my application. Interfaces for the service layer sits in another assembly.
Core utilities/cross-cutting + interfaces (separate assemblies)
This is stuff I build that is not specific to my application, but is not part of the framework or any third party plugin I'm using. Again, interfaces to these components sit in their own assembly.
Repository (EF context)
This is the interface between my domain models and my database. My service layer uses this to retrieve/modify my database via the domain models.
Domain models (EF POCOs)
The EF4 generated POCOs. Some of these may be extended for convenience to other nested properties or computed properties (such as Order.Total = Order.Details.Sum(d => d.Price))
IoC container
This is what is used for injecting my concrete/fake dependencies (services/utilities) into the MVC app & services. Constructor injection is used exclusively throughout.
Here is where I'm struggling:
1) When integration testing is appropriate vs. unit testing. For example, will some assemblies require a mix of both, or is integration testing mainly for the MVC app and unit testing for my services & utilities?
2) Do I bother writing tests against the repository/domain model code? Of course in the case of POCOs, this is not applicable. But what about when I extend my POCOs w/ computed properties?
3) The proper pattern to use for repositories. I know this is very subjective, as every time I see this discussed, it seems everyone has a different approach. Therefore it makes it hard to figure out which way to go. For example, do I roll my own repositories, or just use EF (DbContext) directly?
4) When I write tests for my services, do I mock my repositories, or do I use SQL Lite to build a mock database and test against that? (See debates here and here).
5) Is this an all-or-nothing affair, as in, if I do any testing at all, I should test everything? Or, is it a matter of any testing is better than no testing? If the latter, where are the more important areas to hit first (I'm thinking service layer)?
6) Are there any good books, articles, or sample apps that would help answer most of these questions for me?
I think that's enough for now. If this ends up being too open ended, let me know and I will gladly close. But again, I've already spent months trying to figure this out on my own with no luck.
This is really complex question. Each of your point is large enough to be a separate question so I will write only short summary:
Integration testing and unit testing don't replace each other. You always needs both if you want to have well tested application. Unit test is for testing logic in isolation (usually with help of mocks, stubs, fakes, etc.) whereas integration test is for testing that your components work correctly together (= no mocks, stubs or fakes). When to use integration test and when to use unit test really depends on the code you are testing and on the development approach you are following (for example TDD).
If your POCOs contains any logic you should write unit tests for them. Logic in your repositories is usually heavily dependent on database so mocking context and test them without database is usually useless so you should cover them with integration tests.
It is really dependent on what you expect from repositories. If it is only stupid DbContext / DbSet wrapper then the value of repository is zero and it will most probably not make your code unit testable as described in some referenced debates. If it wraps queries (no LINQ-to-entites in upper layer), expose access to aggregate roots then the meaning of repository is correct separation of data access and exposing mockable interface.
It is fully dependent on previous point. If you expose IQueryable or methods accepting Expression<Func<>> passed to IQueryable internally you cannot correctly mock the repository (well you can but you still need to pair each unit test with integration test testing the same logic). LINQ-to-entities is "side effect" / leaky abstraction. If you completely wrap the queries inside repository and use your own declarative query language (specification pattern) you can mock them.
Any testing is better then no testing. Many methodologies expects high density coverage. TDD goes even to 100% test coverage because test is written always first and there is no logic without test. It is about the methodology you are following and up to your professional decision to chose if you need a test for piece of code.
I don't think that there is any "read this and you will know how to do that". This is software engineering and software engineering is an art. There is no blue print which works in every case (neither in most cases).