При разработке проекта и планировании архитектуры я начинаю с двух направлений. Сначала я смотрю на проектируемый проект и определяю, какие бизнес-проблемы необходимо решить. Я смотрю на людей, которые будут его использовать, и начну с грубого дизайна пользовательского интерфейса. На данный момент я игнорирую данные и просто смотрю на то, что просят пользователи и кто будет их использовать.
Получив базовое понимание того, о чем они просят, я определяю основные данные, которыми они будут манипулировать, и начинаю базовый макет базы данных для этих данных. Затем я начинаю задавать вопросы, чтобы определить бизнес-правила, окружающие данные.
Начав с обоих концов независимо, я могу планировать проект таким образом, чтобы соединить два конца вместе. Я всегда стараюсь как можно дольше сохранять отдельные проекты, прежде чем объединять их вместе, но при этом буду помнить о требованиях каждого.
Когда у меня есть хорошее понимание каждого конца проблемы, я начинаю планировать структуру проекта, которая будет создана для решения проблемы.
После создания базовой схемы решения проекта я смотрю на функциональность проекта и настраиваю базовый набор пространств имен, которые используются в зависимости от типа выполняемой работы. Это могут быть такие как аккаунт, корзина покупок, опросы и т. Д.
Вот базовая схема решения, с которой я всегда начинаю. По мере того, как проекты становятся более определенными, я уточняю их для удовлетворения конкретных потребностей каждого проекта. Некоторые области могут быть объединены с другими, и я могу добавить несколько специальных по мере необходимости.
SolutionName
.ProjectNameDocuments
For large projects there are certain documents that need to be kept with
it. For this I actually create a separate project or folder within the
solution to hold them.
.ProjectNameUnitTest
Unit testing always depends on the project - sometimes it is just really
basic to catch edge cases and sometimes it is set up for full code
coverage. I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
Some projects have specific installation requirements that need to be
handled at a project level.
.ProjectNameClassLibrary
If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
I am adding this because I just found a need for one in my current project.
This project holds the following types of scripts: SQL (Tables, procs,
views), SQL Data update scripts, VBScripts, etc.
.ProjectName
.DataRepository
Contains base data classes and database communication. Sometimes
also hold a directory that contains any SQL procs or other specific
code.
.DataClasses
Contains the base classes, structs, and enums that are used in the
project. These may be related to but not necessarily be connected
to the ones in the data repository.
.Services
Performs all CRUD actions with the Data, done in a way that the
repository can be changed out with no need to rewrite any higher
level code.
.Business
Performs any data calculations or business level data validation,
does most interaction with the Service layer.
.Helpers
I always create a code module that contains helper classes. These
may be extensions on system items, standard validation tools,
regular expressions or custom-built items.
.UserInterface
The user interface is built to display and manipulate the data.
UI Forms always get organized by functional unit namespace with
additional folders for shared forms and custom controls.