Ok 2 questions here.
I am creating a c# application from a vb6 application. I will be using a business logic layer, a data layer, presentation layer, and data layer.
What layer should I start with since the database is already in place?
2nd question. If I code a new app would I start with this same layer?
Which layer to start with is a hard thing to talk about abstractly. It does vary depending on what type of application you are discussing, the size of said application, and the general interdependencies.
If I understand your question correctly it sounds like you are considering writing (say) the entire data layer before moving on to the business layer.
Why start with any one layer? If you writing an application (either from scratch or as a port of an existing app) then why wouldn't you divide that app up into stories and tackel it in more of a feature oriented fashion?
By doing this you will have parts of a functional app that you can prototype with much quicker. This will also allow you to spot design problems in all layers much quicker, as you are not only writing the layers but also consuming them.
I generally prefer starting with the UI. The UI is the point of customer interaction, and so drives the requirements for the rest of the layers.
In some cases, there's some core bit of logic that's really key, and it's a good idea to start there. But generally, I find the UI is the best place to start.
Related
I consider myself quite amateur when it comes to designing a system's architecture, and I currently find myself in the process of doing just that.
Particularly, I am trying to come up with an efficient and maintainable way to re-implement all classes that have methods/functions that query the database to read data, then send it upstream for another layer to process it, and finally receive the processed data to write it back to the database.
Surely this generic problem has already been solved. I intend to follow a DDD approach, so that the methods accessing the database are part of an "Infrastructure" layer. Is there an optimal way of designing a system (or structure of classes) to accomplish this? Should I have just one gateway to read/write from the database that all classes should refer to, or should each components have its own way of communicating with the database? Is there a standard approach to do this?
I am mindful that the question might be a bit broad, but for the experts out there surely you have gone through this and are able to help.
There are following items to be considered:
DAO pattern - Create DAO layer leveraging DAO objects (for each domain object) where upper layer (such as service layer) can make use of it.
Architecture - If you are thinking about micro-services architecture, then UI, Service, DB access (DAO) & DB - all these will be single deployable unit. Hence, design pattern will be aligned to chosen architectural approach.
API Gateway - An API gateway (aligned with architectural approach). Think about functional use-cases while designing APIs rather than just providing CRUD operations or technology specific APIs.
As an accepted practice, your presentation layer, business logic and data access(some call it back end layer) should be fairly separated. Microst's MVC concept is just a sensible example of dedicated effort to achieve this. AngularJs from Google is another example of MVVM that is to write clean code on client side as opposed to Asp.net MVC server side. So what should be the best practices is clearly established here. As for your question, I would say to design something qualify for highly optimized designing paradigm does not require a certain way but an experience of knowing somany ways and wisdom to choose single or multiple ways or even mixing them to suit your needs. As for your question about gateway to data access, let me put it this way, maintain multiple connections is a very resource consuming job so ideally a single static instance data class in which a single connection is maintained is an appropriate approach and all the data serving, manipulating methods should be put in there. In web development, we are familiar with webservices exposing objects with operation / message contracts. Separation and encapsulation is the key here. But be sure nothing is perfect, though Asp.net MVC boasts the best methodology of separating all these layers, they have Razor to contradict it. But it's necessary. Hell with being paranoid with tightly coupled back and front end or spaghetti code. It all makes sense when it suits your needs. The key here only experience can teach us the optimize way or ways to do something. That's the returned value of my answer!
I am trying to use the Model View Presenter (MVP) pattern for a software that I am writing. I am using C# and Windows Forms, althought that should not matter for answering my question.
I have multiple "MVP-structures". One, for example, is handling retained mode graphics where I can draw geometric shapes on a canvas. Another one is taking these shapes, doing some analysis on them and putting the result somewhere else. There are potentially many events that cause controllers to manipulate data somewhere which then causes cascading manipulation of data in yet another place and so forth.
My fear is that I will eventually loose track of what is changing what if I do not organise my software properly. I can think of two ways to organise the interactions between programm parts occuring in my software: either hierarchical or switch board-like.
My question is: Are there any well known approaches or patterns, that I should look up to organise my software? I would need a starting point for my web search.
I think your intuition is right. If you create many events that cascade you are going to end in trouble. I've seen many times over-complex applications due to out of control eventing. This makes the code very difficult to debug and improve.
First thing it came to my mind was the mediator pattern. Elaborating a bit more I would have central classes that manage parts of the business logic. I would have the model in each of the MVP lightweight , basically being a client that asks the server (one of this controller classes) for more complicated business logic. The idea is to have every model of the MVP classes interacting with as few classes as possible (core business logic) and avoid interacting with other MVPs (which will have more specific business logic)
In any case I would limit as much as possible the classes that throw and listen to events and would centralize this in as few places as possible. The observer pattern can help here. Also having a client-server architecture with a service layer containing the heavy business logic can help making this decoupled and maintanable in the future.
The pattern service layer from the fowler classic "patterns of enterprise application architecture" could be good reading too.
I am trying to wrap my head around the domain driven design concept of the service layer, both application services and domain services. Virtually all of the examples I've come across have to do with CRUD applications with databases. I'm having trouble understanding how these concepts map to graphical applications like the example application I've chosen for this question, a clone of Microsoft Paint developed in .NET/C#.
I read the basic concept of a service layer in DDD and an expanded explanation. I have chosen the following application layers:
Infrastructure (cross-cutting)
Logging
Data (filesystem)
BitmapImage, PngImage, etc.
Domain
Canvas, Image, Selection, Shape, Brush, etc.
Application
Presentation (local client WPF)
Views
ViewModels
One use case I'm trying to design is the user drawing a rectangle on the canvas. From what I've read, since the use case requires the cooperation of several domain objects a domain service, DrawingService, would make sense.
Another use case would be the user loading a file to be displayed. Again, from what I've read, since this use case is a command and a workflow, an application service, FileLoadingService, would make sense.
As Martin Fowler describes, I believe Microsoft Paint is complex enough to warrant a service subsystem, here based on thematic behaviors. However, as the application grows, the service layers could be refactored to fall into partitions of the domain model, e.g. CanvasService, SelectionService, etc. Would than then necessitate another layer of abstraction, perhaps an application facade, now that multiple services must cooperate?
Update 1:
Initial comments suggest DDD architecture is not a good fit for a drawing application. Any suggestions for an alternative?
imho a drawing application is not a very good fit for DDD. It would use something else
The reason for asking this question is that I've been wondering on how to stitch all these different concepts together. There are many examples and discussions on i.e. DDD, Dependency Injection, CQRS, SOA, MVC but not so many examples on how to put them all together in a flexible way.
My goal:
Develop modules that with little or no modification can stand on their own
Changing or reworking the UI should be as easy as possible (i.e. the UI should do as little as possible, and be "stupid"
Use documented patterns and principles
To make it easier to ask a concrete question, the main arcitecture now looks like this:
The example shows how to add a note to an employee. Employee Management is one bounded context. Employee has several properties, among those an ICollection<Note>.
The bound context is in my understanding the logic place to seperate code. Each BC is a module. Most of the time I find each of them can warrant their own UI if needed (i.e. some modules might be made available for Windows phone).
The Domain holds all business logic.
The infrastructure holds repository implementation, and services to send mail, save files and utilities that does not belong in the domain. I'm thinking of making some of the common service feautures that I have to use in several domains (like send e-mail) as a sort of an API that I could reference to save some code implementing the same things across several BC's.
The query layer holds all Querys except GetById that I need in the repository to fetch an object. The query layer can query other persistence instances, and will probably need to change some for each UI.
The Wcf or Web Api is kind of my Application layer, it might belong in infrastrucure and not on the outside. This service also sets up the dependencies, so all UI need to do is to ask for information and send commands.
The process starts with the blue arrows. Read the model since that has most of the information.
In step 1 the EmployeeDto in this example is just some of employee properties to show the user information about the employee they need to make a note on (like a note about new experience or something like that).
So, the questions are:
Does implementing a layered arcitecture like this really involve so much mapping, or have I missed something?
Is it recommended (or even smart) to use a Wcf service to run the main logic like this (it practically is my Application Service)
Are there alternatives to Wcf without having my domain objects in my UI layer?
Is there anything wrong with this implementation. Any fall pits to look out for?
Do you have any good examples to recommend looking at that can help me to understand how all these concepts are supposed to work together.
Update:
I've read through most of the articles now (quite a bit of reading) except for the paid book (requires a bit more time to do). All of them are very good pointers, and the way of thinking of the Wcf of more as an adapter seems to be a good answer to question 2. JGauffins work on his framework is also very interesting if I'm planning to go the that route.
However, as mentioned in some of the comments beneath I feel some of the examples tends towards recommending or implementing event and/or command sourcing, message buses and so on. To me it is overkill to plan for that level of scaling right now. As many business applications this is a "large" (in terms of an internal application, think max a few thousand) number of users working on a large set of data, not a highly collaborative domain in the sense of needing to implement event and command queues often assosiated with CQRS to cope with that.
Based on the answers below, the approach I'll start with will be based on the model above and the answers like this:
I'll just have to cope with mapping. Thoe pros outweighs the cons.
I'll pull application services back to the infrastructure and
consider Wcf as an "adapter"
I'll use command objects and send to application service. Not
polluting my domain with domain objects.
To keep complexity down I try to manage without event/command
sourcing, message buses etc for now.
In addition I just wanted to link to this blog post by Udi Dahan about CQRS, I think things like this keeps complexity down unless they are really needed.
There is a trade-off between mapping and layers. One reason certain mappings exist is because appropriate abstractions aren't available or feasible. As a result, it is often easier to just explicitly map between layers than trying to implement a framework that infers the mappings, but I digress; this hinges on a philosophical discussion of the issue.
The WCF or WebAPI service should be very thin. Think of it as an adapter in a hexagonal architecture. It should delegate everything to an application service. There is conflation of the term service which causes confusion. Overall, the goal of WCF or WebAPI is to "adapt" your domain to a specific technology such as HTTP. WCF can be thought of as implementing an open host service in DDD lingo.
You mentioned WebAPI which is an alternative if you want HTTP. Most importantly, be aware of the role of this adapting layer. As you state, it is best to have the UI depend on DTOs and generally the contract of a service implemented with WCF or WebAPI or anything else. This keeps things simple and allows you to vary implementation of your domain without affecting consumers of open host services.
You should always be on the lookout for needless complexity. Layering is a trade-off and sometimes it can be overkill. For example, in an app that is primarily CRUD, there is no need to layer this much. Also, as stated above, don't think of WCF services as being application services. Instead, think of them as adapters between a transport technology and application services. In turn, think of application services as being a facade over you domain, regardless of whether your domain is implemented with DDD or a transaction script approach.
What really helped me understand is the referenced article on the hexagonal architecture. This way, you can view your domain as being at the core and you layer things around it, adapting your domain to infrastructure and services. What you have seems to already follow these principles. A great, in-depth resource for all of this is Implementing Domain-Driven Design by Vaughn Vernon, specifically the chapter on architecture.
Does implementing a layered architecture like this really involve so much mapping, or have I missed something?
Yes. The thing is that it's not the same object. It's different representations of the same object, but specialized for each use case. A view model contains logic to update the GUI, a DTO is specialized for transfer (might get normalized to ease transfer). etc. etc. They might look the same, but they really aren't.
You could of course try to put all adaptations into a single class, but that would not be very fun to work with when your application grows.
Is it recommended (or even smart) to use a Wcf service to run the main logic like this (it practically is my Application Service)
You need some kind of networking layer. I wouldn't let all client applications touch my database. It would create a maintenance nightmare if you mess with the database schema (if some of the clients still run the old version).
By using a server it's much easier to maintain version differences.
Do note the a WCF service definition should be treated as constant once being used. Any changes should be defined in a new interface (for instance MyService2).
Are there alternatives to Wcf without having my domain objects in my UI layer?
You could take a look at my framework. Start post: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/
Is there anything wrong with this implementation.
Not that I can see. Looks like you have a pretty good grasp of the concepts and how they should be used.
Any fall pits to look out for?
Don't try to be lazy with the queries and commands. Don't make them a bit more generic to fit several use cases. It will come back and bite you when the application grows. Smaller classes is easier to maintain.
Do you have any good examples to recommend looking at that can help me to understand how all these concepts are supposed to work together.
The my linked blog post and all other articles in that series.
I'm developing an three layer ASP.NET application with C# and Visual Studio 2008 SP1. I'm using WebForms.
I'm wondering to convert that application to a Silverlight application. Maybe I can reuse a lot of code of ASP.NET layer.
What do you think about?
Assuming you have the typical presentation, business logic, and data layers, and also assuming that you have separated your code diligently into these layers, you should be able to replace your Web Forms with a Silverlight interface and leave your BL and DAL intact.
Real projects tend to be somewhat messy, however, making such a transition more difficult. If you're using SqlDataSource you might have problems.
Those are some good points #Andy, and to expand on what he said:
i'm doing that very same thing right now. Because i have a rather comprehensive business layer, i have been able to do a lot of work (a couple of weeks worth), and in that time i have only had to add one function to that business layer. This is important because it reduces the amount of testing required. It also makes any remaining testing easier as it is easier to compare the output of the old version of the application with the new version.
One pattern that really helped to achieve this was the facade pattern. I built a WCF layer that sits over top of the business layer, and by using the facade pattern i can return results that are more suitable for the new silverlight interface, without interfering with the business layer.
It is most likely though that your new UI will have a drastically different architecture than the ASP.NET version. You will be able to achieve a far cleaner separation between UI, code and data. Some of the ASP.NET code that i was quite proud of looks positively mangy next to the equivalent silverlight code. Be prepared to chop your old code up, and eliminate those business rules from the immediate code behind :)
If you're goal is simply to replicate the UI behaviour as delivered by ASP.NET then yes assuming good partitioning you could re-use quite a bit of code. You'd have ask why you would want to do that though.
On the other hand if the goal is to provide a much richer interactive experience to the user then its likely that you'll find even a well designed business layer just doesn't behave the way such a radically different UI needs it to.